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METHOD FOR OPERATING NETWORKED 
GAMING DEVICES 
BACKGROUND OF THE INVENTION 

This invention relates generally to gaming devices, and 
more particularly to a method and apparatus for controlling 
gaming devices interconnected by a computer network. 

Networked gaming devices are know in the art Intercon- 
necting a plurality of gaming devices such as slot machines 
via a computer network to a central computer provides many 
advantages. The primary advantage of networked gaming 
devices is the ability to extract accounting data from the i 
individual gaming devices as well as providing player: 
tracking. An example of a data collection system is! 
described in U.S. Pat No. 4,283,709 issued to Lucero et aL i 
Network systems such as described in Lucero et al. allow the ; 
central host computer to monitor the usage and payout, ; 
collectively known as audit data, of the individual gaming 
devices. This audit data includes data related to the number 
of coins or tokens inserted into the device, the number of 
times the device has been played, the amount paid in raises, 
the number and the type of jackpots paid by the machine, the : 
number of door openings, etc. The host computer can then i 
compile an accounting report based on the audit data from: 
each of the individual gaming devices. This report can then i 
be used by management, for example, to assess the profit- \ 
ability of the individual gaming devices. 

Player tracking, as the name indicates, involves tracking \ 
individual player usage of gaming devices. In prior art 
player tracking systems, the player is issued a player iden- 
tification card which has encoded thereon a player identifi- j 
cation number mat uniquely identifies the player. The indi- i 
vidual gaming devices are fitted with a card reader, into i 
which the player inserts a player tracking card prior to I 
playing the associated gaming device. The card reader reads \ 
the player identification number off the card and informs a i 
central computer connected thereto of the player's subse- i 
quent gaming activity. By tracking the individual players, \ 
individual player usage can be monitored by associating 
certain of the audit data with the player identification 
numbers. This allows gaming establishments to target indi- 
vidual players with direct marketing techniques according to i 
the individual's usage. 

One problem that can occur with current player tracking ] - 
systems is mat the player can insert a player identification 
card incorrectly unbeknownst to the player. Currently, if a 
player inserts a player identification card improperly into the 
card reader, a message appears on a display located away \ 
from the card reader. Unfortunately, the player may not be I 
looking at the display while inserting the card. As a result, : 
the player may not see the message on the display. Another i 
prior art approach has been to provide a light emitting diode i 
on the gaming device to indicate to the player the status of \ 
the card insertion. This too has been ineffective because the i 
player may not know the purpose of the LED or the LED i 
may be drowned out by all the other lights of the casino. The i 
player may therefore commence playing with the card \ 
improperly inserted. In this case, both the player and the 
casino lose valuable player tracking information. This is 
frustrating for the player because his activity will not be 
credited to his account and frustrating for the casino because 
the casino's records will be incomplete. Accordingly, a need 
remains for an improved method and apparatus for inform- : 
ing the player when a player tracking card has been improp- 
erly inserted. 

The full power of networked gaming devices has not been i 
completely realized. Although the audit data indicates which i 
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devices are being under utilized and when, there is currently 
no automated method for altering under utilized gaming 
devices' configurations to make them more attractive to 
play. For example, during certain hours of the day, e.g. four 
5 to six a.m., the audit data may indicate that the machines are 
being under utilized. Thus, it would be desirable to recon- 
figure the under utilized gaming devices to provide an 
additional incentive to players to use these devices. In the 
past casinos have run "bonuses" during these times. An 
10 example of such bonuses include a "double jackpot" i 
wherein a player hitting a jackpot is paid double the jackpot 
amount Currently this is implemented by having an atten- 
dant manually payout the additional payout amount This i 
manual technique, however, is cumbersome and inefficient ^ 
15 to administer because an attendant must be constantly super- 
vising the bonusing gaming devices. Accordingly, a need 
remains for an automated method and apparatus to provide 
bonusing for gaming devices. 
Another limitation of the current bonusing systems is that 
2° only predetennmed machines are eligible for the bonusing. 
For example, in a progressive bonusing machine a plurality 
of machines are connected together to form a bank. Only the i 
machines in the bank are then eligible to win the progressive 
jackpot. Thus, a casino must dedicate a certain number of its 
25 machines to these banks. This limits the casino's flexibility i 
in tailoring its bonusing to the number and make-up of its 
customers. Accordingly, a need remains for a more flexible 
bonusing system whereby any of the casino's machines can 
participate in the bonusing. 
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SUMMARY OF THE INVENTION 
It is, therefore, an object of the invention to reconfigure \ 
gaming devices remotely over a network to provide bonus- 
35 ing ' 

Another object of the invention is to provide an integrated i 
system usable with a variety of gaming devices made by 
different manufacturers. 

Another object of the invention is to integrate player 
w tracking, data collection, and bonusing over the same net- i 
work. 

A further object of the invention is to provide visual I 
feedback to the user when a player tracking card has been ^ 
improperly inserted. 
45 A system for operating networked gaming devices is 
described. The system according to the invention allows a 
casino in which the system is installed to run promotions or i 
bonuses on any properly equipped gaming machines while i 
simultaneously gathering player tracking and accounting i 
50 data from all machines. The system provides the capability ! 
for the casino to select which of the plurality of machines are ] 
used in any given promotion. The system further allows any 
number of different promotions to operate simultaneously. \ 
The system includes a plurality of gaming devices or ^ 
55 machines connected to an associated floor controller over a 
network. The system includes one or more of said floor 
controllers. The floor controllers are interconnected by a ! 
high-speed network, such as an Ethernet network, to a i 
database where accounting and player tracking data is i 
60 stored. The system can also include pit terminals and/or fill i 
and jackpot processing terminals. Each promotion involves 
sending a reconfiguration command from the floor controller 
to a gaming device that has been selected to be part of a 
given promotion over the associated network. Upon receipt i 
65 of the reconfiguration command, the gaming device rccon- i 
figures its payout schedule in accordance with the received 
reconfiguration command. In the preferred embodiment this I 
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reconfiguration includes activating a bonus payout schedule. 
A partial list of the promotions according to the invention 
include, but are not limited to: a multiple jackpot wherein 
the gaming device reconfigures its payout to be a multiple of 
its default payout schedule; a bonus jackpot wherein the 
gaming device reconfigures its payout schedule to payout an 
additional bonus amount when certain conditions are met; 
and a progressive jackpot wherein two or more gaming : 
devices are combined in a progressive jackpot having a i 
progressive jackpot payout schedule. In addition to these, 
many other promotions are possible by the above-described 
system for controlling and monitoring a plurality of gaming 
devices. 

The system also allows for improved player tracking by i 
recording each and every machine transaction including I 
time of play, machine number, duration of play, coins in, 
coins out, hand paid jackpots and games played. The player 
tracking is conducted over the same network as the account- 
ing data is extracted. This allows the invention to provide i 
bonusing to certain individual players as well as during \ 
certain times. As with standard player tracking, the above- I 
described system monitors and reports how many coins are 
played by each player. The system according to the 
invention, however, also includes the ability to record how 
long each player spends at each machine and the number of 
coins won, games played, and hand jackpots won by each \ 
player. The invention is able to record all this information \ 
because the system operates on a transaction by transaction i 
basis. Each transaction, whether it be a coin in, a handle pull, 
etc., is recorded by the system. Other systems simply 
compile the player tracking information at the completion of 
play. All this information is stored on the database, which 
can be later analyzed for future targeted direct mailing i 
campaigns. The player tracking according to the invention i 
also allows the casino to schedule buses and other groups 
and measure their profitability. The system also allows for 
cashless play as well as advanced accounting and security 
features. 

An advantage of the invention is that any of the casino's j 
machines can be incorporated into a bonus promotion. 

Another advantage of the invention is that several bonus j 
promotions can operate simultaneously. 

A further advantage of the invention is the ability to 
record each and every machine transaction including time of 
play, machine number, duration of play, coins in, coins out, 
hand paid jackpots and games played. 

A further advantage of the invention is the ability to i 
associate a player with a certain machine. 

A further advantage of the invention is the ability to i 
perform more targeted direct mailing based on individual 
play. 

A further advantage of the invention is the ability to 
calculate a theoretical win exactly. 

A further advantage of the invention is the ability to i 
generate jackpot announcements, which provides for, among i 
other things, better slot tournaments. 

A yet further advantage of the invention is the ability to 
quickly and easily add new machines to the network. 

The foregoing and other objects, features and advantages i 
of the invention will become more readily apparent from the \ 
following detailed description of a preferred embodiment of i 
the invention which proceeds with reference to the accom- 
panying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is an illustration of a system for monitoring and i 
configuring gaming devices according to the invention. 
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FIG. 2 is a block diagram of an electronic module 
associated with each gaming device to permit monitoring 
and configuring thereof. 

FIG. 3 is a schematic diagram of a data communication 
node of the electronic module of FIG. 2. 

FIG. 4 is a schematic diagram of a discrete machine 
interface circuit of the electronic module of FIG. 2. 

FIG. 5 is a schematic diagram of a player tracking module 
of the electronic module of FIG. 2. 

FIG. 6 is a schematic diagram of a card reader circuit of 
the electronic module of FIG. 2. 

FIG. 7 A is an exploded view of a card reader according 
to the invention. 

FIG. 7B is a rear perspective view of the card reader of 
FIG. 7A. 

FIG. 7C is a front perspective view of the card reader of 
FIG. 7A. 

FIG. 8 is a schematic diagram of a display circuit of the 
player tracking module of FIG. 2. 

FIG. 9 is a schematic diagram of a personality board of the 
electronic module of FIG. 2. 

FIG. 10 is a schematic diagram of a triac driver circuit of 
the electronic module of FIG. 2. 

FIG. 11 is a schematic diagram of a relay driver circuit of i 
the electronic module of FIG. 2. 

FIG. 12 is a block diagram of a communication board i 
included in each floor controller of FIG. 1. 

FIG. 13 is a flow chart for the power-on procedure for the : 
data communication node (DCN) of FIG. 2, which is imple- | 
mented in firmware executed by the DCN controller. 

FIG. 14 is a flow chart for processing of the discrete 
gaming device inputs, of FIG. 13. 

FIG. IS is a flow chart for the step of incrementing meter 
counts associated with each gaming device of FIG. 14, 
which is implemented in firmware executed by the DCN 
controller. 

FIG. 16 is a flow chart for the step of processing the serial i 
interface between the gaming device and the data commu- i 
nication node of FIG. 13, which is implemented in firmware j 
executed by the DCN controller. 

FIG. 17 is a flow chart for the step of processing the j 
network interface between the floor controller and the data i 
communication node of FIG. 13, which is implemented in i 
firmware executed by the DCN controller. 

FIG. 18 is a flow chart for the step of processing the i 
network message of FIG. 17, which is implemented in \ 
firmware executed by the DCN controller. 

FIG. 19 is a flow chart for the step of processing the data \ 
communication node request of FIG. 18, which is imple- 
mented in firmware executed by the DCN controller. 

FIG. 20 is a flow chart for the step of FIG. 13 of 
processing the player tracking interface, which is imple- i 
mented in firmware executed by the DCN controller. 

FIG. 21 is a flow chart for the step of processing a valid 
inserted card of FIG. 20, which is implemented in firmware 
executed by the DCN controller. 

FIG. 22 is a flow chart for the step of processing player 
tracking information of FIG. 21, which is implemented in 
firmware executed by the DCN controller. 

FIG. 23 is a flow chart for the power-on procedure for the 
player tracking (PT) node of FIG. 2, which is implemented 
in firmware executed by the PT controller. 

FIG. 24 is a flow chart for the step of processing the DCN 
interface of FIG. 23. which is implemented in firmware 
executed by the PT controller. 
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FIG. 25 is a flow chart for the step of processing the DCN 
message of FIG. 24, which is implemented in firmware 
executed by the FT controller. 

FIG. 26 is a flow chart for the step of processing the card 
reader bezel update of FIG. 23, which is implemented in 
firmware executed by the FT controller. 

FIG. 27 is a flow chart for the step of processing the card 
reader of FIG. 23, which is implemented in firmware 
executed by the FT controller. 

FIG. 28 is a flow chart for the power-on floor controller 
process, which is implemented in software executed by the 
floor controller. 

FIG. 29 is a flow chart for the message processing step of : 
FIG. 28, which is implemented in software executed by the \ 
floor controller. 

FIG. 30 is a flow chart for the message handling step of j 
FIG. 29, which is implemented in software executed by the : 
floor controller. 

FIG. 31 is a flow chart for the step of assigning unique \ 
machine addresses of FIG. 30, which is implemented in: 
software executed by the floor controller. 

FIG. 32 is a flow chart for the system monitoring step of \ 
FIG. 28, which is implemented in software executed by thej 
floor controller. 

FIG. 33 is a flow chart for the event handling step of FIG. : 
32, which is implemented in software executed by the floor: 
controller. 

FIG. 34 is a flow chart for bonus control, which isj 
implemented in software executed by the floor controller. : 

DETAILED DESCRIPTION 
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5. PROCESSING NETWORK INTERFACE 

6. PROCESSING PLAYER TRACKING INTERFACE 

7. PROCESSING CARD INSERTION 

B. PLAYER TRACKING MODULE 
5 1. POWER UP PROCEDURE 

2. PROCESSING DCN INTERFACE 

3. PROCESSING DISPLAY UPDATE 

4. PROCESSING BEZEL UPDATE 
io 5. PROCESSING CARD READER 

C. FLOOR CONTROLLER 

1. POWER UP PROCEDURE 

2. MESSAGE PROCESSING 

15 3. ASSIGNING GAMING DEVICE ADDRESSES 

4. SYSTEM MONITORING 

5. BONUS CONTROL 

I. SYSTEM ORGANIZATION 
20 A. SYSTEM OVERVIEW 

A system far operating a plurality of gaming devices is 
shown generally at 10 in FIG. 1. The system, hereinafter 
described, monitors and reconfigures a plurality of gaming 
devices or machines 12-16 and 22-26. The system includes 
25 the following capabilities: remote reconfiguration, account- 
ing data extraction, integrated player (racking, and cashless 
play. Remote reconfiguration includes sending a reconfigu- 
ration command from a host computer to one or more of the 
gaming devices. The gaming devices, on receiving a recon- 
30 figuration command, will reconfigure its jackpot payout 
schedule in accordance with the reconfiguration command. 

This reconfiguration, in the preferred embodiment, com- 
prises activating a bonus payout schedule. This bonus pay- 
out schedule is in addition to the normal pay table of the 
35 gaming device. The bonus payout schedule provides for 
additional bonus payouts in addition to the payouts specified 
by the device's normal pay table. The difference between the 
two is important for regulatory reasons. The composition of 
the pay table is subject to regulation by the various state 
40 gaming commissions while the bonus payout schedule is 
not The preferred embodiment currently activates only the 
bonus payout schedule responsive to the reconfiguration 
command, while not altering the payout table. The 
invention, however, is not limited to activating only the 
45 bonus payout schedule. Other embodiments, which would 
be subject to regulatory approval, could modify the device's 
payout table. The preferred embodiment, however, does not 
The system, according to the invention, implements a 
variety of bonusing events through this reconfiguration 
so process. These bonusing events include: a multiple jackpot 
wherein the gaming device reconfigures its payout to be a 
multiple of its default payout schedule; a bonus jackpot 
wherein the gaming device reconfigures its payout schedule 
to payout an additional bonus amount when certain condi- 
55 tions are met; and a progressive jackpot wherein two or more 
gaming devices are combined in a progressive jackpot 
having a progressive jackpot payout schedule. 

The system, according to the invention, also provides for 
integrated player tracking and accounting data extraction. : 
60 Unlike prior art systems that use disparate systems for player 
tracking and accounting data exlraction, the system 10 
provides for player tracking and accounting data extraction 
over the same network. The player tracking, according to the 
invention, allows the casino to run certain promotional i 
65 events. The integrated player tracking and accounting data ^ 
extraction also allows the system to support cashless play 
wherein a credit is given to a player over the network. 
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The system 10 includes one or more floor controllers 18; 
and 28. Each floor controller supports up to a predetermined! 
maximum number of gaming devices. In the preferred: 
embodiment, each floor controller can support up to 1024: 
gaming devices. The preferred embodiment also supports up 
to eight floor controllers. Thus, the system 10 can support up 
to 8192 separate gaming devices. 

The system supports a multiplicity of various gaming: 
devices. The gaming devices 12-16 and 22-26 shown in: 
FIG. 1 are the type having a pull handle for initiating a game, ! 
e.g.. slot machines. However, the invention is not limited to 
such gaming devices. The gaming devices shown in FIG. 1 \ 
can also be gaming tables or push button operated machines ! 
as well. e.g, video poker. As will be described hereinafter,: 
the system supports any gaming device providing traditional : 
discrete connections, e.g., coins-in, coins-out etc., as well as \ 
those having serial interfaces, as described below. 

The floor controllers 18 and 28 are, in the preferred: 
embodiment. IBM-compatible personal computers. Each: 
floor controller is responsible for monitoring the activity: 
level of the corresponding gaming devices connected thereto : 
and issuing commands to the associated gaming devices to 
reconfigure their payout schedules during certain bonusingi 
events. The floor controllers issue status requests to each of! 
the individual gaming devices to determine the activity level : 
of each. In the event the floor controller detects any activity, : 
the floor controller communicates that activity to a file: 
server 32, which is connected to the floor controllers via a 
high speed network 38 connected therebetween. 

In the preferred embodiment, the file server 32 includes a 
high performance personal computer or work station having: 
a large hard disk capacity in order to store the gaming device : 
activity therein. In the preferred embodiment, the high speed : 
network 38 is a ten megabyte ethemet network. The system! 
10 also includes commercially available network software to! 
support the industry-standard ethernet network 38. An: 
example of such network software is Novell network soft-: 
ware sold by Novell of Provo, Utah. The file server 32 also: 
includes a database program by which reports can be gen- 
erated using the data stored on the file server. Such reports! 
include, e.g. area, model, denomination and summary 
reports. The database software also allows a user to generate 
custom reports. The database software is based on the 
industry-standard Paradox database language. 

The system 10 also includes a pit terminal 34 which is 
also connected to the ethernet network 38. The pit terminal 
34 is also a standard personal computer, in the preferred 
embodiment, and can be used to monitor the gaming device 
activity in the pit. This terminal 34 can also be used as a 
security monitoring device to detect any unanticipated 
events like fills or payouts. 

The system 10 further includes any number of fill and 
jackpot processing terminals 36. These terminals 36 are 
placed in the cage and/or the change booth areas of the 
casino for fill and hand-paid jackpot processing. When a fill 
is required, a floor person goes to the nearest cashier's booth 
and states the gaming device number requiring a fill. The 
booth attendant enters the number into the fill and jackpot 
processing terminal 36 located in the cashier's booth. The 
terminal 36 then looks up the record associated with the! 
particular gaming device in the file server 32 to determine! 
the correct fill amount The terminal 36 also calculates a! 
theoretical hopper balance for the particular device based on ! 
the latest meter information, as described further below. If! 
the calculation shows a significant hopper balance, a warn-! 
ing is given on the computer screen from which security can ! 
then be alerted. 
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A fill and jackpot processing terminal 36 prints a nil ticket 
upon demand. If the calculated hopper balance was nearly 
zero, the terminal 36 cause the words "computer verified" to 
be printed on the ticket in place of a supervisor's signature. 
5 In the event that the calculated hopper balance was not near 
zero, an extra signature is required to complete the fill 
transaction. The system follows a similar procedure for 
processing hand-paid jackpots. 
A dispatch station (not shown) can also be included in the ; 

10 system. The dispatch station allows the casino to monitor 
activity on the gaming devices and "run the casino" from i 
one location. The dispatch station allows the dispatcher to i 
monitor customer service, maintenance, and security events i 
and direct other casino personnel to handle these situations 

15 appropriately. For example, during hopper empties (fills) 
and jackpot events, as indicated by the dispatcher station, the 
dispatcher could radio down to the floor to have someone 
verify the event The dispatcher station can also indicate 
when a machine door is opened without a technician card i 

20 inserted, for example, in which case the dispatcher could i 
take the appropriate course of action. 

The above-described system 10 is but one embodiment of 
the system according to die invention. The system tasks can 
be allocated in a variety of ways amongst the system i 

2s computers including floor controllers 18 and 28, file server 
32, pit terminal 34 and fill and jackpot terminals 36. In some 
cases, the pit terminal 34 and fill and jackpot terminals 36 
can even be eliminated and their tasks allocated to the floor 
controller or file server. In fact, because the file server 32 is 

30 essentially a virtual hard disk for the floor controllers 18 and 
32, the floor controllers and the file server can be considered 
a single host computer for the system 10. 
B. DATA COMMUNICATION NODE 

1. OVERVIEW 

35 In order to communicate with the floor controller, each 
gaming device includes therein an electronic module 40, as 
shown in FIG. 2. This module 40 can be inserted into a 
variety of pre-existing gaming devices. The module allows 
the host computer to uniquely identify the gaming device on 

40 the network, including the device type. The module 40 
includes two main subcomponents: a data communication 
node 42 and a player tracking module 44. The data com- : 
munication node 42 keeps track of the coins-in, coins-out, i 
coins to drop, games played, jackpot occurrences and other i 

45 related functions of the associated gaming device. The i 
player tracking module 44 keeps track of the player that is 
playing the associated gaming device. Together, the data 
communication node 42 and the player tracking module 44 
allow the floor controller connected to the associated gaming 

50 device to monitor and control the activity of the gaming 
device. The system hereinafter described in detail includes 
the following capabilities: slot accounting, player tracking, 
bonus jackpots and cashless play. 

2. CONTROLLER AND MEMORY 

55 The data communication node (DCN) 42 includes a data 
communication node controller 46. which in the preferred j 
embodiment is an HD6473258P10 controller manufactured i 
by Hitachi of Tokyo. Japan. The DCN 42 is coupled to the i 
player tracking controller 44 through bus interface logic 45. 

60 The bus interface logic 45 is conventional interface logic 
including, for example, transceivers, as is known in the art 
of digital design. 

A memory 48 is connected to the DCN controller 46. The i 
memory includes program memory for storing program 

65 instructions for the DCN controller 46. In the preferred 
embodiment, this program memory includes a nonvolatile 
read-only memory (ROM). However, this program memory 
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could also be flash or "battery" backed RAM in order for the 
program memory to be updated by the floor controller. In the 
event flash or "battery" back RAM is used the floor con- 
troller would download the updated program to the DCN 
controller and the DCN controller would overwrite the 
program memory with the downloaded program. 

The memory 48 also includes system memory, e.g., static 
random-access memory (SRAM) for storing the gaming 
device information. This gaming device information 
includes at least the following meters: coins-in, coins-out, 
coins to drop, games played, jackpot occurrences. A separate 
meter counter is kept in memory 48 for each of these values. 
To increase reliability of the data, in the preferred 
embodiment, a redundant set of these counters is kept in a 
physically separate memory device within memory 48. 
Moreover, the memory devices storing these counters are 
nonvolatile so that in the event of a power failure the counts 
will be retained. The nonvolatile memories can either be 
battery-backed SRAM or electrically erasable program- : 
mable read-only memory (EEPROM). Although memory 48 j 
is shown external to DCN controller 46, much if not all of 
the memory 48 can be included in the DCN controller 46. ; 

3. NETWORK INTERFACE 

The data communication node 42 also includes a network 
interface 49 for connecting the data communication node 42 
to the associated floor controller. The network interface is | 
coupled to the floor controller through a personality board I 
202, described below. 

A more detailed drawing of network interface 49 is shown i 
in FIG. 3. In FIG. 3, the DCN controller 46 receives data i 
from the floor controller over conductor 52 which is opti- i 
cally isolated from a connector 51 by optical isolator circuit 
54. The DCN controller 46 transmits data to the floor 
controller over conductor 56, which is optically isolated 
from the connector 51 by optical isolator circuit 58. Each of 
the opto-isolator circuits 54 and 58 include an opto-coupler 
as are known in the art A bus 222 (FIG. 2) is connected j 
between the network interface 49 and the personality board i 
202. 

4. SERIAL MACHINE INTERFACE 

Referring to FIG. 2, the data communication nodei 
includes a serial machine interface 60. The serial machine j 
interface 60 allows the data communication node 42 to 
communicate with the associated gaming device advance 
serial interface as contrasted with the discrete interface, to be 
described further hereinafter. A bus 224 (FIG. 2) connects 
the serial machine interface 60 to the associated gaming 
device at connector 62. The serial interface, in the preferred 
embodiment, is a standard RS232 three wire interface. 

Referring to FIG. 3, the DCN controller 46 receives data \ 
from the gaming device over conductor 64 which is con- \ 
nected between the DCN controller 46 and a differential to i 
single-ended converter 66. The DCN controller 46 transmits j 
data to the gaming device over conductor 68 connected j 
between the DCN controller 46 and the converter 66. The i 
converter 66 converts the differential inputs of the serial 
interface 62 to a single-ended output which is transmitted 
over conductor 64 to the DCN controller 46. The converter 
66 also converts the single-ended input received from the 
DCN controller 46 to a differential output signal and trans- 
mits that to the serial interface 62. The serial machine 
interface is the means by which the DCN controller com- ; 
municates certain reconfiguration data, referred to as recon- i 
figuration commands, to the machine. These reconfiguration \ 
commands cause the machines to activate a bonus payout \ 
table to allow the machine to append bonus payments to 
their standard jackpot payouts, as specified by their payout j 
table, during certain bonus activities. 
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5. SERIAL DISPLAY INTERFACE 

The data communication node 42 further includes a serial 
display interface 70 illustrated in more detail in FIG. 3. The 
serial display interface 70 includes logic coupled between 
5 the DCN controller 46 and an expansion connector 71. The 
expansion connector 71 allows the DCN controller 46 to 
communicate with an expansion device connected thereto. 

6. DISCRETE MACHINE INTERFACE 

The data communication node 42 also includes a discrete 

10 machine interface 72, which is shown in detail in FIG. 4. The 
discrete machine interface 72 includes a plurality of opto- \ 
couplers 78 coupled between the discrete outputs from the \ 
gaming device or machine and the DCN controller 46. The : 
discrete outputs of the machine are received at terminals 

15 74A-74J of a connector 74 via a cable (not shown) con- j 
nected between the machine and the connector 74. The \ 
discrete outputs are coupled to corresponding inputs i 
76A-76J via opto-couplers 78. The discrete outputs from the \ 
machine include: an EXTRA signal, a POWER signal, a 

20 COm IN signal, a COIN OUT signal, a COIN DROP signal, i 
a JACKPOT signal, a HANDLE signal, a TUT signal, a i 
SLOT DOOR signal, and a DROP DOOR signal Each of I 
these signals correspond to a known event in the machine. 
For example, when a coin is dropped in the machine a COIN 

25 IN signal appears on terminal 74C. This COIN IN signal is 
then transmitted to the DCN controller 46 on line 76C via 
the associated opto-coupler. 

All of the signal lines 76A-76J include a pullup resistor 
and a pulldown capacitor, which combined form an RC 

30 network on the associated line. The resistors are, in the 
preferred embodiment, in the form of a resistor pack 80 and 
the capacitors are individual discrete capacitors 82. 
Alternatively, the capacitors can be removed for high-speed 
signals. 

35 7. MACHINE CONFIGURATION CIRCUIT 

The data communication node 42, as shown in FIGS. 2 
and 3, further includes a machine configuration circuit 84. In 
the preferred embodiment, as shown in FIG. 3, the machine 
configuration circuit 84 includes a parallel to serial converter 

40 86, which includes eight parallel inputs IN, a serial input 
SIN, a clock input CLK, a strobe input STB, and a serial 
output SOUT. The parallel inputs IN are connected to a 
personality board, as described hereinafter, to receive a 
unique machine configuration number therefrom, which 

45 uniquely identifies the type of machine that the data com- 
munication node is connected to. In the preferred 
embodiment, the machine identification number is com- 
prised of six bits. Therefore, the two remaining parallel 
inputs can be used to provide additional inputs, such as 

50 additional discrete machine inputs, to the DCN controller 
46. 

The machine configuration number presented on the par- 
allel inputs of the parallel to serial converter 86 is latched 
therein responsive to a strobe signal received at the strobe 

55 STB input A strobe input is generated by the DCN control- 
ler 46 on conductor 90 which is coupled to the strobe STB 
input The parallel data is clocked out of the converter 86 to 
the DCN controller 46 on conductor 88 and connected 
between the serial output SOUT of the converter 86 and an 

60 input of the DCN controller 46 responsive to a clock signal 
received on the clock input CLK of the converter 86. The 
clock signal is generated by the DCN controller 46 and is 
transmitted to the converter 86 via conductor 92 which is 
coupled between an output of the DCN controller 46 and the 

65 clock input CLK of the converter 86. 

The converter 86 also includes a serial input SIN for 
receiving serial input data. The serial input SIN is coupled 
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to an expansion terminal 94C of expansion connector 94. 
Conductors 90 and 92 are also coupled to the expansion 
terminal 94 to provide the clock and strobe signals thereto. 
The expansion terminal 94 therefore provides the means for 
the DCN controller 46 to access additional serial informa- 
tion through the parallel to serial converter 86. In the 
preferred embodiment, the parallel to serial converter 86 is : 
part number 4021 manufactured by Toshiba Corporation of; 
Tokyo, Japan. 

C. PLAYER TRACKING MODULE 

1. OVERVIEW 

Referring again to FIG. 2, the module 40 coupled to each 
of the gaming devices includes a player tracking module 44. 
The player tracking (FT) module 44 includes a player 
tracking controller 98. a card reader 100, a serial display 
driver 101. a display 102. and expansion interfaces 104 and 
106. The player tracking controller 98 communicates with 
the data communication node controller 46 through bus 
interface logic 110. The DCN controller 46 and FT controller 
98 maintain a master-slave relationship, respectively.: 
Therefore, all communication is initiated by the DCN con- i 
trailer 46. The bus interface logic is conventional logic and i 
its design is well-known in the art of digital electronics. 

In the preferred embodiment, the player tracking module 
44, with the exception of the card reader 100 and the display 
102, resides on a single printed circuit board, while the data I 
communication node 42 resides on a separate printed circuit i 
board. The player tracking module 44 and the data commu- \ 
nication node 42 are men connected by a cable 111 such as : 
a ribbon cable. 

2. SERIAL DISPLAY CIRCUIT 

A more detailed drawing of the player tracking module 44 
is shown in FIG. 5. In FIG. 5, the serial display circuit 101 
includes a transistor Ql and a resistor Rl connected to the 
base thereof. A conductor 112 is connected between the FT 
controller 98 and the resistor Rl to provide a drive signal to 
transistor Ql. The drive signal causes transistor Ql to 
conduct a current and thereby drive a display connected to 
the collector of Ql at a terminal 114 of a connector 115. In 
the preferred embodiment, the terminal 114 is connectable to 
a small vacuum florescent display to provide serial display 
data thereto. 

3. SERIAL EXPANSION PORTS 

The player tracking module 44 also includes two serial i 
expansion ports 104 and 106. Each of the expansion ports : 
104 and 106 includes a differential to single-ended converter j 
116 and 118, respectively. In the preferred embodiment, j 
these converters 116 and 118 are part number LTC490I 
manufactured by Linear Technology Corporation of I 
Milpitas, Calif. The PT controller 98 communicates with ; 
each converter via two single-ended, serial signal lines: an 
input signal line and an output signal line. The converters 
convert the single ended signals appearing on these lines to 
differential signals. The differential signals, however, can be 
used as single-ended signals as is known in the art. The first 
expansion port 104 interfaces the player tracking node 44 
with a large vacuum florescent display 102 (FIG. 5) used to 
display player tracking messages, as described further 
below. The display is connected to the connecter 115, in the 
preferred embodiment, by a cable 103. The other expansion j 
ports 106 provides the player tracking module with future i 
expansion capabilities to support additional features. 

4. CARD READER 

Referring now to FIGS. 6 and 7. the card reader 100 will : 
now be described. FIG. 6 shows the electrical schematic for i 
the card reader while FIG. 7 shows the mechanical drawing i 
thereof. In FIG. 7A. an exploded view of the card reader is \ 
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shown. The card reader includes a plastic bezel 116 having 
a card reader opening 118 formed therealong for receiving a 
card 120 therein. The bezel 116 includes guide rails 122 and 
124 disposed at opposite, respective lateral ends of the 
5 opening 118. The guide rails 122 and 124 have stops 126 and 
128. respectively. The guide rails 122 and 124 guide the card 
120 through the opening 118 until an end of the card 120 
contacts stops 126 and 128. The card is shown fully inserted 
in FIGS. 7B and 7C with the end of the card 120 abutting the 
10 stops 126, 128. 

The card reader also includes a printed circuit board 130 
having a longitudinal opening to allow the guide rails 122 
and 124 to be inserted therein in order to allow the printed i 
circuit board 130 to be pushed up flush against a mounting 
15 plate 132 of the bezel 116, as shown in FIGS. 7B and 7C. 
Mounted on one side of the printed circuit board 130 is an i 
array of photodiodes 134 and an array of photodetectors 136. i 
The photodiodes 134 are mounted on the printed circuit 
board along one side of the opening in the printed circuit 
20 board, while the photo detectors 136 are mounted on the \ 
printed circuit board along an opposite side of the opening, j 
The photodiodes and the photodetectors are vertically j 
aligned in a one-to-one relationship, i.e., one photodiode for i 
each photodetector. In the preferred embodiment, the array 
25 of photodiodes includes eight individual diodes spaced 
equidistance along the opening in the printed circuit board I 
130. The photodiodes 134 are mounted along the opening in I 
the printed circuit board 130 so as to align with separate I 
rows of openings in the card 120, as described further below. 
30 The card reader also includes optional light masks 138 and 
140. The light mask 138 is associated with the array of 
photodiodes 134 and has a plurality of openings therein, 
each opening corresponding to an individual photodiode in 
the array 134. Similarly, light mask 140 is associated with I 
35 the array of photodetectors 136 and also has one opening for j 
each of the photodetectors. The light mask 138 is mounted i 
on the printed circuit board 130 beneath the array of pho- i 
todiodes 134 along the opening in the printed circuit board i 
130. The light mask 138 is aligned with the photodetectors 
40 134 so that the openings in the light mask 138 are directly 
beneath a corresponding photodiode in the array. The light j 
mask 138 minimizes the amount of light emitted by a ^ 
photodiode that can be detected by a photodetector other 
than the corresponding photodetector. The light mask 140 is 
45 mounted on top of the photodetector array 136 so that the 
openings therein align with the individual photodetectors. 
The light mask 140 further eliminates extraneous light from j 
the photodiodes as well as extraneous ambient light 
Also mounted on the printed circuit board 130 are a 
50 plurality of light-emitting diodes 142. as shown in FIG. 7C 
in broken line. The light-emitting diodes are mounted on a 
side of the printed circuit board opposite the side on which 
the photodiodes and photodetectors are mounted on. The i 
light-emitting diodes 142 are mounted around the perimeter I 
55 of the opening in the printed circuit board 130 and are 
received in a recessed portion 144 of the bezel 116. The 
light-emitting diodes 142 comprise a means for providing i 
visual feedback to a user inserting a card 120 into the bezel i 
116, as described further below. In the preferred 
60 embodiment, the light-emitting diodes 142 are dual light- 
emitting diodes capable of producing two primary colors 
and a third combination color. 

Referring now to FIG. 6, an electrical schematic of the \ 
card reader is shown. The schematic includes the array of j 
65 photodiodes 134 disposed along one side of the card reader 
opening 118 and the array of photodetectors 136 disposed 
along the opposite side of the opening 118. In the preferred 
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embodiment, there are eight photodiodes and eight corre- 
sponding photodetectors. The photodiodes are arranged in 
pairs, with the two photodiodes within each pair being 
connected in a serial fashion. The anode of the first photo- 
diode in the pair is coupled to the supply voltage through 
resistor, while the cathode of a second photodiode in the pan- 
is connected to an output of a driver circuit 144. The driver 
circuit, in the preferred embodiment, includes two open i 
collector inverters connected in parallel. A signal is provided I 
to the driver circuit 144 by the FT controller 98 over a 
conductor 146. A signal on conductor 146 causes the driver 
circuit 144 to conduct current and thereby actuate the \ 
photodiodes 134 substantially simultaneously. 

The photodetectors 136 are comprised of a plurality of 
light-sensitive phototransistors PD1-PD8. The emitters of 
the phototransistors PD1-PD8 are all coupled to ground, i 
The collectors of phototransistor PD1 and PD8 are con- ^ 
nected together and to a conductor 148 by which the PT \ 
controller 98 senses light detected by either photolransistor 
PD1 or PD8. Phototransistors PD2 and PD7 are similarly 
connected with the collectors of each being connected to a i 
conductor ISO. The collectors of phototransistors PD3 and I 
PD6 are also commonly connected to a conductor 152. The 
collectors of the center phototransistors PD4 and PDS, 
however, are connected to separate conductors 156 and 154, i 
respectively. Also connected to each of the conductors \ 
148-156 is a corresponding pullup resistor. Jn the preferred 
embodiment, the pullup resistors are included in a resistor 
pack 158. Each of the conductors 148-156 are connected to 
a connector 170, which is coupled to the PT controller 98 as ^ 
described below. 

Based on the above configuration of the phototransistors 
PD1 and PD8, only five conductors are required to sample 
all eight of the phototransistors. Without more information, i 
however, the player tracking controller 98 would be unable \ 
to determine which of the two phototransistors commonly 
connected to a particular conductor, eg., conductor 148, 
detected light For example, if either phototransistor PD1 or ^ 
phototransistor PD8 detect light, the voltage level on con- j 
ductor 148 will drop from a high voltage of approximately 
5 volte to a low voltage of approximately 0.7 volts. Without 
more information, the player tracking controller 98 would be 
unable to determine which of the two phototransistors, PD1 ^ 
or PD8, actually sensed the light According to the invention ] 
however, the card 120, as shown in FIG. 7A, includes a first 
slot 150 by which the PT controller 98 can determine which 
of the two photodetectors detected the light as described 
below. 

The card 120 includes five rows of slots 152-160. The \ 
rows of slots 152-160 are arranged in a matrix with the 
corresponding slot locations within each of the rows being 
aligned in columns. Only the first slot 150 of row 152 cannot i 
be aligned with any other slots, i.e., slot 150 is in a column i 
all by itself. The individual slots within the rows of slots i 
152-160 encode unique player tracking information. Each 
slot represents a single binary bit in the player tracking 
information. Either one of two conventions can be used to i 
encode the information. First, a slot can represent a binary j 
1 and no slot can represent a binary 0. Second, a slot can 
represent a binary 0 and no slot can represent a binary 1. The 
player tracking information can include: a unique player 
identification number, the casino issuing the card, player ! 
membership information, etc. 

In the preferred embodiment, the card includes five rows 
of slots each having a maximum number of nine individual 
slots, thereby producing 45 possible slots. The first row of 
slots 152, however, is not used to encode player tracking i 
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information, but instead is used to synchronize the sampling 
of the player tracking information by the player tracking 
controller 98. Thus, only 36 slots are used to encode player 
tracking information in the preferred embodiment. This still 
5 allows 2* 36 possible combinations, which is more than 
adequate. 

The FT controller 98 uses the first row 152 to synchronize 
the sampling as follows. The FT controller 98 continuously 
samples the outputs of PD4 and PD5 looking for a slot If a 
10 slot is detected on either PD4 and PD5 and no other slots are 
detected by any other phototransistors the FT controller 98 
determines that the detected slot must be slot 150. The FT 
controller 98 then continuously samples the output of the 
phototransistor that detected slot 150. Once a new slot is 
detected by that phototransistor, the PT controller 98 then 
15 samples the outputs of the other phototransistors, Le., 
PD1-PD3 and PD6-PD8, on conductors 148, 150 and 152 I 
for slots in of the other rows. Thus, the PT controller 98 
synchronizes the sampling of the other rows of slots to the 
detection of a slot in the first row 152. 

20 It is important for the card reader to detect the orientation i 
of the card in order to correctly interpret the player identi- 
fication information encoded on the card. The card reader 
detects the orientation of the card 120 by detecting the slot 
150. If slot 150 is detected by phototransistor PD4, then the \ 

25 card reader knows that the card is in the orientation shown \ 
in FIG. 7A. In that case, the card reader knows that the j 
player tracking information is actually being detected on i 
phototransistors PD5-PD8. and can interpret the player 
tracking information accordingly. If, however, phototrans- 

30 istor PD5 detects slot 150, then the card reader knows that 
the card 120is oriented 180 degrees from that shown in FIG. i 
7A. In that case, the card reader knows that the player j 
tracking information is being detected by phototransistors \ 
PD1-PD4, and can interpret the information accordingly. 

35 The PT controller 98 can simply transpose the player track- 
ing information sensed on conductors 148-152 depending 
upon the detected orientation of the card. Thus, the card j 
reader according to the invention is able to correctly inter- i 
pret the player tracking information regardless of how the : 

40 player inserts the card 120 into the bezel 116 of the card j 
reader. The invention is able to accomplish mis with only i 
five conductors between the eight phototransistors i 
PD1-PD8 and the PT controller 98. 
The card reader further includes a plurality of light- i 

45 emitting diodes 142 that are mounted on the printed circuit i 
board 130 and received in the recess 144 of the bezel 116, 
as shown in FIG. 7C. The LEDs 142 are mounted on the 
printed circuit board 130 so as to surround the card reader 
opening 118 as shown in FIG. 6. In the preferred 

50 embodiment, the card reader includes 24 dual diodes 
arranged in pairs. The dual diodes have two separate diodes, 
each being able to emit a different primary color of light In 
the preferred embodiment, the dual diodes emit either red or 
green light The dual diodes can also emit a third combina- 

55 tion color if the two individual diodes in the dual diode are 
actuated simultaneously so that the two primary colors 
combine. In the preferred embodiment, this combination 
color is approximately orange due to the differences in the 
intensities of the red and green light 

60 The dual diodes are essentially treated as two individual 
diodes. The red diodes R in the dual diodes are driven by a 
driver circuit 162, while the green diodes G in the dual 
diodes are driven by another driver circuit 164. The driver 
circuits 162 and 164 are, in the preferred embodiment, two 

65 open collector drivers connected in parallel, as with driver 
145. However, other equivalent driver circuits would be 
apparent to those skilled in the art 
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The dual diodes are arranged in pairs with the anodes of 
one of the dual diodes being coupled to the supply voltage 
+5V and the cathodes of the other dual diode being con- 
nected to the output of the corresponding driver circuit 
Accordingly, the red diodes are commonly driven by driver 
circuit 162, which is responsive to a signal received from the 
FT controller 98 on conductor 166. Similarly, the green ; 
diodes are commonly driven by driver circuit 164, which is ; 
responsive to a signal received from the FT controller 98 on i 
conductor 168. Therefore, the FT controller 98 can selec- i 
tively actuate the red diodes, the green diodes or both by i 
generating the corresponding signals on conductors 166 and ; 
168. 

All of the conductors over which the FT controller com- 
municates with the card reader, i.e.. 146-156 and 166-168, 
are connected to a connector 170 as shown in FIGS. 6 and 
7A. The player tracking module 44 then includes a cable 172 
that is connected between the comiectc-r 170 and the FT \ 
controller 98. as shown in FIG. 5. 

Although the preferred embodiment of the card reader is j 
an optical card reader, the invention is not limited to such, i 
The lighted bezel can be used in conjunction with any form 
of card reader such as a magnetic card reader, a bar code 
reader, etc. The method of providing visual feedback to the 
player herein described is a general method which can be 
used with a plurality of cards and card readers. 

5. DISPLAY 

Referring now to FIG. 8, a schematic for the display i 
circuit 102 of the player tracking module 44 is shown. The j 
circuit 102 includes a display controller 174, which in the 
preferred embodiment is a part number HD6473258P10 
manufactured by Hitachi of Tokyo, Japan. Coupled to the 
display controller 174 is a memory 176 via bus 178. The 
memory 176, in the preferred embodiment, is a 32KB 
SRAM. The memory 176 stores the variables and param- \ 
eters necessary for the controller 174 to communicate with \ 
both the FT controller 98 and the display driver 186. The bus j 
178 includes the necessary address lines, data lines and i 
control lines to interface in memory 176. 

In the preferred embodiment, the display 102 includes a 
vacuum fluorescent display (VFD) 184, which is organized 
as a 16x192 display matrix. Such displays are well-known 
in the art of digital electronics. The VFD 184 is driven by a 
driver circuit 186, which includes a plurality of individual i 
drivers serially interconnected. In the preferred! 
embodiment, these serial drivers are part number; 
UCN5818EPF-1. manufactured by Allegro Microsystems, i 
Inc. of Worcester, Mass. The driver circuit 186 is connected i 
to the VFD 184 by bus 188 which includes 160 individual | 
conductors. The manner in which the 160 bus lines are 
connected between the driver circuit 186 and the VFD 184 
is known in the art, and is therefore not described in detail 
herein. 

The display controller 174 interfaces with the driver 
circuit 186 by a plurality of signal lines 190. These signal j 
lines transmit the standard driver interface signals to the i 
driver circuit 186. These signals include: a clock signal i 
CLOCK, serial input data signal SDATA, a frame signal i 
FRAME a strobe signal STROBE, two output enable sig- i 
nals OEl/and OE2/. a column clock signal COL CLOCK, 
and a column output enable signal COL OE/. These signals 
have well known functions in the display art and are therefor 
not discussed in detail. The signal names having a T 
represent active low signals while all other signals are active 
high. The display controller 174 generates these signals in 
the required sequence in order to serially clock the refor- \ 
matted display data to the driver circuit. One of ordinary i 
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skill in the art could program the display controller 176 to 
generate these signals in order to display the desired mes- 
sage on the VFD 184 based on the foregoing description. 
The display 102 also includes a serial interface 192. The 
5 serial interface 192 is the means by which the PT controller 
98 communicates a player tracking message to me display 
102. In the preferred embodiment, the serial interface 192 
includes two opto-isolator circuits: one for the serial send 
data, the other for the serial transmission data. The display 
io controller 174 is connected to the serial interface 192 over 
a two conductor serial bus 194, one conductor for receiving 
serial data from the serial interface 192, the other for 
transmitting serial data thereto. A connector 196 is also 
coupled to the serial interface 192. The connector 196 
is includes four terminals. Two of the connector terminals are 
dedicated to receiving serial input data and the other two 
terminals are dedicated to transmitting serial data. A cable 
(not shown) couples the display 102 to the player tracking 
module 44 between connectors 196 (FIG. 8) and connector 
20 115 (FIG. 5). 

6. DISCRETE INPUT SECTION 
The display 102 further includes a discrete input section 
198. The discrete input section 198 is an interface between 
the discrete outputs of a gaming device and the display 
25 controller 174 much in the same way that the discrete 
machine interface 72 allows the data communication node to 
interface with a gaming device. Although in the preferred 
embodiment the discrete input section is unconnected to any 
discrete machine inputs, the discrete input section 198 
30 allows the display 102 to operate as a stand-alone module for 
gaming devices in certain configurations. The discrete input 
section provides discrete input signals from an external 
device to the display controller 174 over a bus 200. The 
discrete input section 198 includes opto-isolator circuits 
35 such as part number TLP620 manufactured by Toshiba 
Corporation of Tokyo, Japan which provide single-ended 
input signals to the display controller 174. 
D. PERSONALITY BOARD 
Referring now to FIG. 9. a personality board 202 is shown 
40 in schematic form. The personality board 202 uniquely 
identifies the gaming device on the network. The personality 
board 202 indicates the type of gaming device, e.g., slot 
machine or video poker, including the manufacturer, and 
provides a unique machine identification number that the 
45 host computer can use to uniquely address the gaming 
device. The personality board 202 allows the devices to be 
readily removed and reinstalled in the network without any 
manual reconfiguration by the operator, such as resetting dip 
switches. 

so The personality board 202 couples the data communica- 
tion node 42 to a gaming device. The personality board 202 
includes two connectors 204 and 206 and an identification i 
circuit 208. The connector 204 couples to the data commu- i 
nication node 42, as described further below. The connector \ 

55 206 connects to the particular gaming device. The compo- 
nents shown in FIG. 9 are mounted on a printed circuit board 
that is mounted inside a connector harness (not shown). The i 
personality board allows the DCN to be easily removed and i 
reinstalled from the network with minimal effort 

60 The personality board uniquely identifies the machine by \ 
providing both a configuration number, which indicates the \ 
type of gaming device that is connected to the connector 206 i 
and a unique identification number, which is used by the i 
system 10 to maintain records on the machine. The configu- j 

65 ration number includes a six bit binary number which \ 
indicates the type of gaming device connected to the per- i 
sonality board 202. Each machine type is assigned a unique i 
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configuration number. This configuration number is encoded 
on lines CNFG0-CNFG5, which are connected to terminals ; 
204Q-204V, respectively, of connector 204. Each line rep- 
resents one bit of the binary configuration number. The ; 
individual lines are either tied to a supply voltage to repre- 
sent a binary one or to ground to represent a binary zero. The 
six bit configuration number used in the preferred embodi- 
ment can encode up to T 6 different combinations and, 
therefore, different machine types. The configuration num- ; 
ber for the embodiment shown in FIG. 9 is equal to 3CH. \ 
The configuration lines CNFG0-CNFG5 are coupled to ; 
the inputs of parallel to serial converter 86 (FIG. 3) through ; 
a connector (not shown). The terminals 204Q-204V of; 
connector 204 have corresponding terminals 85Q-85V of 
connector 85, as indicated by corresponding lettered suf- 
fixes. This same lettering convention is used throughout 

The configuration number is used by the DCN controller 
46 as a means of interpreting the discrete input signals 
received from the machine through connector 206. Ihdi- ; 
vidual conductors coupled between connector 204 and 206 ; 
are labeled to correspond to the machine type having a ; 
configuration number 3CH. For a different machine type ; 
having a different configuration number, many of these ; 
Conductors may have different functions. By providing a 
unique configuration number, the DCN controller can inter- 
pret the signals received on these lines accordingly. 

The personality board 202 also includes an identification 
circuit 208 which provides a unique machine identification ; 
number to the data communication node 42. The unique ; 
identification number is stored in a nonvolatile memory 210 j 
and provided to a terminal 204N on conductor ID. In the; 
preferred embodiment, the nonvolatile memory 210 is a part \ 
number DS2224 manufactured by Dallas Semiconductor of; 
Dallas, Tex. In the preferred embodiment, the nonvolatile 
memory 210 includes a 32 bit ROM having a f actory-lasered 
unique serial number stored therein. This serial number, i.e., 
the machine identification number, can be read out of the 
memory 210 by the DCN controller 46 to uniquely identify ; 
the machine connected thereto. The protocol for reading the ; 
identification number out of the memory 210, as is described ; 
in the data sheet for the part, is well known in the art 

The identification circuit 208 includes a number of dis-l 
crete components. The memory 210 has a zener diode 212 
coupled across the power and ground terminals of 213 and 
215 thereof. The identification circuit 202 also includes a 
first diode 214 coupled between the power terminal 213 and ; 
a data output terminal 217. The circuit 208 further includes \ 
a second diode 216 coupled between the data output termi- ; 
nal 217 and the ground terminals 215. A resistor 218 is; 
interposed between the data output terminal 217 and the 
connector terminal 204N. The terminal 204N is coupled to 
a corresponding terminal 74N of connector 74 (FIG. 4) by 
a bus 220 (FIG. 2). 

The discrete outputs from the machine, e.g., coin in, coin ; 
out etc., are also supplied to the data communication node: 
42 via bus 220. The bus 220 connects connector 74 of the; 
data communication node 42 and the connector 204 of the; 
personality board 202 such that terminals having corre-; 
spending lettered suffixes are connected. For example, ter- 
minal 74C of connector 74 is connected to tennmal 204C of 
connector 204 by a individual conductor within bus 220. All 
the other terminals are similarly connected by the bus 220. 

The network interface 49 of the data communication node; 
42 is also coupled to the personality board by a bus 222, as; 
shown in FIG. 2. Bus 222 includes four conductors which; 
connects the four terminals of connector 51 with four; 
corresponding terminals of connector 204, as indicated by; 
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the common lettered suffixes. It is over these four lines that 
the DCN controller 46 indirectly communicates with the 
floor controller. 
The serial machine interface 60 is also coupled to the 

5 personality board 202 by a bus 224, as shown in FIG. 2. The 
bus 224 includes four conductors which couple four termi- 
nals 62DD and 62EE of connector 62 with corresponding 
terminals 204DD and 204EE, respectively. It is over these 
four conductors that the DCN controller 46 communicates 
reconfiguration commands to the machine. The DCN con- 

1 trailer transmits data through the terminal 204DD, which is 
provided to the machine on conductor MACHINE RX. The 
machine responds to the configuration command on the 
conductor MACHINE TX. The use of these two conductors \ 
will become more apparent in the description of Ihe opera- \ 

15 tion hereinbelow. 

Although buses 220, 222, 224 and 226 have been : 
described as separate buses, the individual conductors i 
within these buses could, and are in the preferred 
embodiment, combined into a single bus that is connected 

20 between the data collection node 42 and the personality 
board 202. To connect the data collection node 42 and the 
personality board 202 a connector (not shown) is mounted 
on the data collection node 42 and a mating connector (not 
shown) is mounted on the personality board 202. The two 

25 connectors are then mated together to connect the data 
collection node 42 to the personality board 202. The per- 
sonality board is then coupled to the corresponding gaming 
device by a cable 225 (FIG. 2). 

E. BONUS DISPLAY DRIVERS 

30 Referring now to FIGS. 10 and 11, two bonus display 
drivers are shown. The data communication node 42 is 
designed to support either of the display drivers. The data 
communication node 42 is coupled to the display driver of 
FIG. 10 through connector 228. An opto coupler 230 opti- 

35 cally isolates the data communication node from a triac 
circuit 232 which includes a triac 234. One terminal of the 
triac 234 is connected to a terminal 236B of a connector 236. 
Another terminal of the triac 234 is connected to a terminal 
236C of connector 236. A bonus display such as a light or 

40 sound generating means is coupled across terminals 236B 
and 236C so that the triac 234 could drive the external bonus 
display responsive to an actuation signal from the data 
communication node 42. 
A second embodiment of the display driver is shown in 

45 FIG. 11. In this embodiment, the data communication node 
42 is coupled to the driver circuit through connector 238. 
The driver circuit of FIG. 11 includes a relay 240 operatively 
coupled to a transistor 242. The relay 240 is a two-position 
relay which toggles between the two positions responsive to 

50 a current passing through transistor 242. The transistor 242 
conducts a current responsive to an actuation signal received 
on terminal 238B from the data communication node 42. 

The display drivers are used by the data communication 
node 42 to activate a display on the gaming device which 

55 indicates that the machine is now in a bonus mode or 
condition. 

F. FLOOR CONTROLLER 

As shown in FIG. 1, the floor controller is directly 
connected to both the high speed network 38 and a plurality 

60 of gaming devices. The floor controller is responsible for 
monitoring the activity of each of the gaming devices 
connected thereto and reporting mis activity to the database 
32. In addition, the floor controller is responsible for trans- 
mitting a reconfiguration command to a selected one or more 

65 of the gaming devices during certain bonus conditions. 
These conditions will be described in detail in the operation 
section below. 
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The floor controller is connected to the associated gaming 
devices by current loop networks. Because of the limitations 
of the current loop network, only a predetermined number of 
gaming devices can be supported on any one current loop 
network. In the preferred embodiment, each current loop 
network supports up to 64 gaming devices. In order for each 
floor controller to support more than this predetermined 
number of gaming devices, each floor controller is equipped 
with a communication board 246. as shown in FIG. 12. The i 
communication board 246 supports up to 16 separate current 
loop networks. The board is a standard size card that fits into 
one of the ISA card slots in the back of the floor controller. 
The board includes a male edge connector (not shown) 
which mates with a female back plane connector (not 
shown) in the floor controller. The back plane connector 
provides the floor controller CPU data, address, and control 
lines to the communication board 246 to enable the com- 
munication board and the floor controller CPU to commu- 1 
nicate. 

The communication board 246 includes eight separate 
microcontrollers 248A-248H. The microcontrollers com- 
municate with the floor controller through ISA bus interface 
logic 247 over buses 249A and 249B. The microcontrollers 
are shown in a daisy-chain connection in FIG. 12, but any i 
other equivalent interconnection scheme can be used. The i 
data received from the floor controller microprocessor is i 
passed between the microcontrollers from 248A to 248H, as i 
indicated by the arrows. Each microcontroller is responsible 
for passing the data along and determining whether the data 
includes a message for a machine connected to its corre- 
sponding current loop networks. 

Each microcontroller is responsible for two current loop I 
networks. Each microcontroller communicates with its asso- i 
dated gaming devices via two corresponding current loop! 
networks. Two serial signal lines 251 connect each micro- 1 
controller to a current loop driver circuit 250. The driver 
circuit 250 provides the necessary current drive to support 
the current loop network. Each pair of serial signal lines 251 
has a corresponding pair of current loop lines 253. The! 
current loop driver circuit 250 can either be located on the i 
communication board as shown in FIG. 12 or on a separate \ 
printed circuit board (not shown). If located on a separate j 
board, the current loop driver circuit 250 can be connected i 
to the communication board by a cable. 

In the preferred embodiment, the last microcontroller 
248H is solely responsible for cornmunicating with the floor 
controller microprocessor. All of the data received from the : 
machines over the various current loop networks are passed! 
along to the microcontroller 248H by the associated micro- ; 
controller. The microcontroller 248H analyses the data and! 
determines whether the data needs to be communicated to 
the floor controller. If not, the last microcontroller records i 
the communication but does not forward the data to the floor 
controller. This helps off-load some of the floor controller 
communication processing to the communication board. 

II OPERATION 

The above-described system allows a casino in which the: 
system is installed to run promotions on any properly j 
equipped gaming machines while simultaneously gathering i 
player tracking and accounting data from all machines. The! 
system provides the capability for the casino to select which 
of the plurality of machines are used in any given promotion. 
The system farther allows any number of different promo- 
tions to operate simultaneously. 

Each promotion involves sending a reconfiguration com-i 
mand from the floor controller to a gaming device that has i 
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been selected to be part of a given promotion over the 
associated network. Upon receipt of the reconfiguration 
command, the gaming device reconfigures its payout sched- 
ule in accordance with the received reconfiguration com- 
5 mand. As described above, reconfiguring a gaming device 
payout schedule, in the preferred embodiment, includes 
activating a bonus payout schedule that pays out bonus 
amounts in addition to the amount determined by the device 
payout table. 

10 A partial list of the promotions according to the invention 
include, but are not limited to: a multiple jackpot wherein 
the gaming device reconfigures its payout to be a multiple of 
its default payout schedule; a bonus jackpot wherein the 
gaming device reconfigures its payout schedule to payout an 

15 additional bonus amount when certain conditions are met; 
and a progressive jackpot wherein two or more gaming 
devices are combined in a progressive jackpot having a 
progressive jackpot payout schedule. In addition to these, 
many other promotions are possible by the above-described 

20 system for controlling and monitoring a plurality of gaming 
devices. 

The system 10 also allows for improved player tracking. 
As with standard player tracking, the above-described sys- 

2J tern monitors and reports how many coins are played by 
each player. The system 10, however, also includes the 
ability to record how long each player spends at each 
machine and the number of coins won, games played, and 
hand jackpots won by each player. All this information is 

jo stored on the database, which can be later analyzed for 
future targeted direct mailing campaigns. The player track- 
ing according to the invention also allows the casino to 
schedule buses and other groups and measure their profit- 
ability. The system also allows for cashless play as well as 

35 advanced accounting and security features. 

Another feature of the above-described system is jackpot 
announcements. The jackpot announcement feature displays 
a message on a reader board or display located in the casino 
which announces a jackpot as soon as a jackpot is won, i.e.. 
as soon as the reels stop spinning. The floor controller 
generates the jackpot announcement once a DCN connected 
thereto indicates a jackpot is won. An example of such a 
message might be: "Now paying on machine 1342, a jackpot 
of $300." With prior art data collection systems, the amount 

45 of the jackpot is only known after the payment is made. Even 
then the system must account for partial pays, hopper empty, 
etc. 

An advantage of the current system over prior art systems 
is the ability to implement better tournament systems. In a 

so slot tournament, players pay a fee to play. All play during the 
session is free. The players accumulate credits instead of 
cash. The person with the most credits at the end of the 
tournament wins. Games are usually manually altered to 
provide payouts of 200 to 300% to make the games more \ 

55 fun. The games are altered manually by replacing the read 
only memory (ROM) in the gaming devices. 

One exciting aspect of tournament play is to see who is 
ahead. No current system can display this information in real 
time. This is because current systems can only measure I 

60 winnings as they are added to the credit meter or paid from 
the hopper (some casinos use tournament tokens instead). 
Since credits are usually added at a rate of 10 per second, a 
1.000 credit win can take 100 seconds to register. Casinos : 
attempting to create display boards showing who is ahead j 

65 are frustrated by the lag time. The jackpot announcement of 
the invention allows casinos to display the player with the 
most credits by comparing the number of credits for each 
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player. This comparison and display is performed real time 
as each transaction is completed. 

In order to implement each of these features, the various 
computers and microcontrollers each execute software or 
firmware. This software and firmware routines are described 
below. These routines are described with reference to 
accompanying flow charts. These flow charts would enable 
one of ordinary skill in the art of computer programming to 
write a corresponding computer program which the com- 
puter or microcontroller could execute. 
A. DATA COMMUNICATION NODE 

1. POWER UP PROCEDURE 

Referring now to FIG. 13, a power up procedure 252 for 
the data communication node is shown. This procedure is 
executed by the DCN controller 46 when initially powered 
up. The first step of the procedure is to validate the RAM to 
ensure that it is not corrupted and to set up all the DCN 
hardware. Validating the RAM involves writing known 
patterns of Is and Os to the DCN RAM. This RAM can either 
be internal to the DCN controller 42 or external as shown in 
FIG. 2. Setting up the DCN hardware includes initializing 
timers and interrupts. 

Next the DCN controller checks the RAM in step 255 by 
reading the pattern of Is and Os back out of the RAM to 
ensure that the RAM is fully functional. If the RAM turns 
out to be defective the DCN controller goes into an endless 
loop in 256. 

2. READING UNIQUE IDENTIFICATION NUMBER 
If the RAM is fully functional, the DCN then reads the 

unique identification number from the personality board. As 
described above, this unique identification number is stored 
in a nonvolatile memory 210 on the personality board. 
Reading the unique ID number out of the nonvolatile 
memory involves following the memory manufacturer's 
interface protocol as specified in the nonvolatile memory 
data sheet. The unique identification number provides a \ 
means for uniquely identifying the gaming device. 

After the unique ID has been read from the personality : 
board, the DCN processes the discrete machine inputs in ! 
step 260. This step will be described in further detail in I 
Subsection 3, MONITORING GAMING DEVICE DIS- j 
CRETE INPUT below. After the discrete inputs have been \ 
processed in step 260, the DCN processes the machine serial i 
interface in step 262. This step is described further below in 
Subsection 4, PROCESSING GAMING DEVICE SERIAL 
INTERFACE. Next, the DCN processes the network 
interface, i.e., the interface between the DCN and the floor 
controller connected thereto. The process network interface 
step 264 is described further below in Subsection 5, PRO- 
CESSING NETWORK INTERFACE. Finally, the DCN 
processes the player tracking interface in step 266. This step 
is described below in Subsection 6, PROCESSING CARD 
INSERTION. At the completion of step 266 the DCN loops ; 
back to step 260 and continuously, sequentially executes I 
steps 260-266. 

3. MONITORING GAMING DEVICE DISCRETE ! 
INPUT 

Referring now to FIG. 14, the DCN step of monitoring the j 
gaming device discrete inputs 260 will now be described. \ 
The DCN first reads the discrete inputs on input lines 76 in \ 
step 267. One particular set of discrete inputs is shown in i 
FIGS. 4 and 9 for a particular gaming device. The actual i 
discrete inputs present will depend on the machine type, as 
indicated by the configuration number, which is also read by 
the DCN controller 46. Most gaming devices provide at least 
some of the following discrete inputs: coins in, coins out, 
coins to drop, games played, attendant paid jackpots, slot 
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door, drop door, progressive jackpots, and bill validators. 
The system supports all of these discrete inputs as well as 
others. 

The DCN keeps track of the machine activity by main- 
5 taining several meters in memory. Each meter, in the pre- 
ferred embodiment, includes six digits. Moreover, to 
improve the reliability of the system, the DCN maintains 
redundant backup copies of these meters with an order to 
replace the original meters in the event that the originals are 
10 corrupted. In step 268, the DCN increments the meters as : 
required based on the discrete inputs. The meters are main- ! 
tained even in the event that the DCN is disconnected from I 
the floor controller. Once the DCN is reconnected to the i 
floor controller, all the activity level information is then | 
is available. Step 268 will be discussed further below. 

Next, the DCN processes the drop door signal in step 270. ! 
The drop door signal DROP DOOR indicates mat the drop i 
door on the machine has been opened. This is an important 
event and is therefore processed separately. 
20 In step 272, the DCN validates the meter values to 
determine whether the values stored in the meters are valid. 
The DCN checks whether the meter values are valid in step 
274. In the preferred embodiment, a check sum is main- 
tained for each meter value. Thus, the DCN in step 274 
25 checks to see whether the check sum is correct based on the 
current meter value. If the meter values are okay, the discrete 
input monitoring step 260 is complete. If the meter values 
are not valid, the DCN replaces the meter values with the 
redundant back copy of the meter values in step 278, and 
30 then the step 260 is complete. 

Referring now to FIG. 15, increment meter step 268 is 
shown in farmer detail. The sequence shown in FIG. 15 is 
repeated for each meter value mat has changed. The first step 
is to adjust the meter value based on the discrete inputs and 
35 to calculate the associated check sum. Next, the DCN 
determines whether the particular meter has an active asso- 
ciated countdown count in step 282. Some games or pro- 
motional activities require the player to reach a certain level 
of activity in order to be eligible for certain bonus points. 
40 These countdown counts are used to determine whether the 
player has achieved this level of activity. For example, the 
player may be required to play a certain number of coins 
before being awarded any points. If the countdown count is 
active, the DCN adjusts the current players count down 
45 values in step 284 based on the corresponding adjustment of 
the associated meter. 

In step 286, the DCN sets the current message to the count 
down message. The count down message indicates to the i 
player when he or she will be eligible for the bonus points, 
so Finally, in step 288 the DCN sets the current bezel color and 
rate to a count down color and rate. This color and rate i 
information is subsequently transmitted to the player track- 
ing node for processing, as described further below. The 
countdown color indicates the bezel color and the count i 
55 down rate indicates that flashing rate of the bezel color 
displayed during the count down message. 
4. PROCESSING GAMING DEVICE SERIAL INTER- 
FACE 

Referring now to FIG. 16, a process 262 for processing i 
60 the gaming device serial interface is shown. The serial 
machine interface 60, as shown in FIG, 2, allows the DCN 
controller 46 to communicate with the gaming device i 
through the personality board. This serial machine interface 
allows the DCN controller 46 to transmit reconfiguration ; 
65 commands to the gaming device in order to reconfigure the i 
payout schedule of the machine in accordance with the 
reconfiguration command. In addition, the serial machine 
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interface provides an additional means for determining the 
activity level of the gaming device. Instead of reading the 
discrete machine inputs, the DCN controller 46 can transmit 
a status request command to the machine over the serial 
interface and the machine can respond back with the 
requested status information. 

Any communication protocol can be used to implement 
this communication path over the serial machine interface, 
as is known in the art. An example of one such protocol uses 
a data packet including a command code, a message 
sequence number, a CRC, and a variable length message. In 
the preferred embodiment, either the DCN controller 46 or 
the machine can initiate communications over the serial 
machine interface. However, if the machine detects that the 
DCN is trying to send a message to the machine, the 
machine must abort its message and attempt to resend the 
message at a later time. 

The preferred embodiment of the system supports many I 
different reconfiguration commands. A partial list of the i 
reconfiguration commands is given below in Table 1. These I 
reconfiguration commands are sent from the DCN controller 
46 to the machine over the serial machine interface wherein 
the machine reconfigures its payout schedule in accordance 
with the particular reconfiguration command. The recon- 
figuration commands do not originate with the DCN, instead 
the reconfiguration commands originate from the floor con- 
troller and are transmitted to a particular machine over the : 
associated current loop network or the command can origi- i 
nate at one of the other computers on the high speed i 
network. The DCN is simply responsible for forwarding the : 
reconfiguration command onto the gaming device on receipt ; 
of the reconfiguration command over the associated current ; 
loop network coupled between the floor controller and the 
DCN. 

Table 1 — Examples of Reconfiguration Commands 

1. Bonus Pay From Hopper (Coin Format) 

2. Bonus Pay to Credit Meter (Coin Format) 

3. Bonus Pay from Hopper (Dollar Format) 

4. Bonus Pay To Credit Meter (Dollar Format) 

5. Add Non-cash outable credits to Game 

6. Begin Double Jackpot Time 

7. Stop Double Jackpot Time 

The actual process of processing the machine serial 
interface begins in step 292 wherein the DCN polls the 
machine to determine its level of activity. This polling step 
includes sending a status message from the DCN to the 
machine over the serial machine interface. In response, the j 
machine will send a packet of status information indicating : 
the current amount of activity on the machine. The status \ 
information included in the response will depend on the type ; 
of machine that the DCN is communication with. 

The data communication node 42, in step 294, waits for i 
a reply to the status request Jf a reply is received, the DCN ; 
indicates that the machine is "on line" in step 296 and 
processes the machine reply in 298. The step of processing 
the machine reply includes updating the meter values, as 
done when processing the discrete inputs. After the machine 
reply has been processed, the process 262 is complete. 

If the DCN does not receive a reply from the machine in 
step 294, the DCN indicates mat the machine is "off line". 
The DCN will wait for a predetermined amount of time i 
before deciding that the reply is not received. In the pre- \ 
ferred embodiment, this predetermined period is approxi- ; 
mately 110 milliseconds. 
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5. PROCESSING NETWORK INTERFACE 
Another step in the DCN power up procedure 252 is the 
step of processing the network interface 264. This step is 
described with reference to FIGS. 17-19. The network 
5 interface refers to the current loop that connects the particu- 
lar DCN with the associated floor controller. The following 
description assumes that the DCN has received a valid 
message from the associated floor controller. Because there 
are multiple DCNs connected to any one current loop, the 
10 floor controller must include some means for addressing a 
particular machine. 

Although each machine includes a unique identification 
number which could be used as the actual address for each 
DCN on the current loop, it is unnecessary to use the unique 

15 identification as the actual address because there are only a 
limited number of DCNs connected to each current loop. 
Accordingly, in the preferred embodiment of the invention, 
the floor controller uses a shorthand token representation of 
the DCN's unique identification number to address the 

20 DCN. In the preferred embodiment, a single byte address is 
used to address a DCN on any given current loop. This 
one-byte address allows up to 256 DCNs to be supported on 
any given current loop network. In the preferred 
embodiment, however, only 64 such DCNs are connected to 

25 a single current loop and therefore the single byte address is 
more than adequate. The single byte address substantially 
reduces the amount of traffic on the current loop network by j 
reducing the number of bytes from four in the unique 
identification number to one for the shorthand token repre- 

30 sentation. 

The floor controller is responsible for generating the I 
unique single byte address for each data communication i 
node on a given current loop network. The process of I 
assigning unique single byte addresses to the DCNs is I 
35 described below in Section C. 

Once all the DCNs have been assigned a unique address, i 
the DCN can begin monitoring the current loop network for 
messages addressed to it If the DCN detects a message 
addressed to it, the DCN executes step 264. The DCN first 
40 checks to see whether the message is valid in step 304. This 
check is done by computing the CRC value of the message 
and comparing it to the CRC included with the message. If j 
the two CRCs match, the message is valid and the DCN 
processes the network message in step 306. Processing the 
45 network message is described further below with reference i 
to FIGS. 18 and 19. Once the message has been processed, 
the DCN sends a reply back to the floor controller over the ! 
current loop networkin step 308. The actual substance of the 
reply will depend on the message received in step 306. If the I 
50 message is invalid, the DCN does not reply. 

Referring now to FIG. 18, the first step of processing the j 
network message is to determine what type of message was 
sent from the floor controller in step 312. There are three 
basic types of messages that the floor controller sends to the I 
55 DCN. The first is a request for data from the DCN. If this 
type of message is detected the DCN builds the data 
requested and transmits the data in a reply message. The i 
main use of this message type is to gather status and meter I 
information from the DCN. 
60 Another type of message is one including configuration 
data for the DCN. This message allows the floor controller 
to implicitly set the DCN's memory to a fixed value. This 
message is used to override the DCN's internal variables, 
e.g., to get a DCN out of a lock-up condition, or to download 
65 new firmware to the DCN for execution. On receiving this 
type of message, the DCN simply overwrites its memory I 
with the configuration data included in the configuration i 
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message in step 316. The DCN men builds an appropriate 
acknowledgment and transmits mis acknowledgment mes- 
sage to the floor controller in step 320. 

The other type of message is one sent in response to a 
DCN request The DCN processes this data in step 318, 
which is described further in FIG. 19. If the message 
includes either the configuration data or the data in response 
to a DCN request, the DCN builds an acknowledge message 
in step 320 and transmits this message to the floor controller. 

The step of processing a floor controller message sent in 
response to a DCN request will now be described with 
reference to FIG. 19. The first step of processing mis type of 
message is for the DCN to determine what type of data is 
included in the message. Once again there are three types of 
data mat can be included in this message type: a reconfigu- 
ration command, card data, or other minor data. The DCN ! 
makes this determination in step 324 by analyzing one of the \ 
bytes in the data packet of the message. This byte will be 
referred to herein as the command byte. If the command byte 
indicates that the message contains reconfiguration data, i.e., 
the command byte equals a reconfiguration command, the ! 
DCN stores the reconfiguration data in a predefined data j 
structure in memory. Listed below in Table 2 is an example ! 
of a data structure for storing the reconfiguration data. 

Table 2 — Reconfiguration Data Structure 

1. Bonus Type 

2. Mystery Jackpot Data: 

A. Number of coins to award 

B. Number of seconds to award 

C. Pay award to 

3. Bonus Time Data 

A. Jackpot Multiplier 

B. Jackpot Payout Limitations 

C. Number of Seconds to Keep Bonus Time Active 

D. Minimum Activity Level 

The bonus type field of the data structure indicates the 
type of bonus state the machine is to be placed in. Examples 
of potential bonus modes include progressive/! 
nonprogressive, multiple jackpot, or mystery jackpot. If the ! 
mystery jackpot is indicated, the mystery jackpot datai 
included in the structure specifies the conditions under 
which the mystery jackpot is paid out The mystery jackpot 
can be set to payout eg., after a certain number of coins in, 
handle pulls, which is specified by subfields of the mystery 
jackpot data. 

The bonus time jackpot is a promotion wherein the: 
machine pays out more than that dictated by its default! 
payout schedule. In one embodiment of the bonus time i 
promotion, the payout schedule of the machine can be 
modified to be a multiple of its default to payout schedule, 
as specified in subfield (A) of the bonus time data. This 
promotion can be used to encourage gaming activity during: 
off-peak hours, e.g., midnight to 4 a.m. on weeknights.! 
Alternatively, the bonus time promotion can be activated on 
a random basis. The timing of the multiple jackpot is 
specified by the casino on one of the computers connected 
to the network. The bonus time data also specifies the 
conditions under which the player becomes eligible for the 
bonus time jackpot The subfield (B) of the bonus time data 
specifies whether the player is eligible for the bonus time! 
data only if the player is playing the maximum coin in the! 
machine. Subfield (C) limits the bonus time promotion to a 
predetermined number of seconds. This field limits the! 
bonus time promotion to a predetermined number of sec- 
onds; if the player does not nit a jackpot within mis specified 
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time period, the bonus time promotion concludes. The; 
minimum activity level can also be specified in subfield (D). 
This field can be used to specify the minimum activity level 
required by the player in order to be eligible for the bonus : 
5 time jackpot. For example, the player can be required to play i 
at least 20 coins over the last three minutes in order to be i 
eligible for the bonus time jackpot An indicator light on the 
player's machine can be used to indicate when the player 
reaches the minimum activity level and thereby becomes 
eligible for the bonus time jackpot 

In another embodiment of the bonus time promotion, a 
bonus amount is awarded in addition to the payout according 
to the default of the payout schedule of the machine. The 
amount of the bonus jackpot is specified in subfield (E) of 
the bonus time data. For example, this bonus time promotion 
might include five bonus amounts of $10, $25, $50, $100 
and $500, which is specified by subfield (E). When a player 
hits a particular jackpot, whichever bonus amount is speci- 
fied by the bonus amount subfield this amount is automati- 
^ cally paid out in addition to the payout amount determined 
by the machine's default payout schedule. This bonus time 
promotion can also be used in combination with subfields 
(C) and (D) to specify the conditions under which the player 
is eligible for this bonus time jackpot award. 

After the DCN has stored the reconfiguration data in step 
326, the DCN will then send the appropriate reconfiguration 
command to the machine over the serial machine interface 
in step 328. The machine, responsive to the received recon- 
figuration command, reconfigures its payout schedule in 
accordance with the received reconfiguration command. For 
example, if the reconfiguration command specifies a mul- 
tiple jackpot condition, the machine will reconfigure its 
payout to be a multiple of its default payout schedule. The 
machine will reconfigure its payout schedule in a similar 
manner for the other bonus types. 

The other type of data that can be included in a response 
from a DCN request is card data or player tracking data. This 
data is sent to the DCN in response to a status message from 
the DCN to the floor controller wherein the status message 
indicates that a player card has been inserted. Included in 
this message is the card ID number detected by the card 
reader. In response to this status message the floor controller 
will transmit a card insertion message to the DCN. The card 
insertion message includes information associated with the 
4J particular player ID number. An exemplary card insertion 
message data packet is listed below in Table 3. 

TABLE 3 — Card Insertion Message Data Packet 

1. Card Identification Number 
50 2. Player First Name 

3. Player Last Name 

4. Current Point Balance 

5. Casino Code 

Upon receipt of the card insertion message, the DCN 
55 stores the player's name and points in order for this infor- 
mation to be displayed on the VFD display associated with 
the player tracking node. Then, a DCN sets the current 
message to a data received message in step 334. Finally, a 
DCN sets the current bezel color and bezel rate to a data 
60 received bezel color and bezel rate in step 336. The bezel 
color specifies the bezel color to be displayed by the card 
reader and the bezel rate specifies the flashing rate of the 
card reader LEDs. This bezel information is subsequently 
transmitted to the player tracking node for processing 
65 thereby. 

The final data type mat can be included in the message 
sent from the floor controller in response to a DCN request 
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is genetically classified as other minor data. This data 
includes general system or DCN specific information such 
as display information. 

6. PROCESSING PLAYER TRACKING INTERFACE 
The next step in the DCN process is processing of the 

player tracking interface 266. The DCN maintains a variable j 
that indicates what message is to be sent to the player 
tracking node. This variable is referred to as the current 
message variable. Before transmitting a message to the 
player tracking node, the DCN first checks this variable to 
see which of a plurality of messages should be sent to the 
player tracking node. 

The process 266 begins in 340 by sending the current 
message to the player tracking node that is specified by the 
current message variable. In addition to the current message, 
the DCN sends the bezel color and bezel rate information to i 
the player tracking node. The bezel color and bezel rate i 
information could have been specified by the floor controller 
or by the DCN itself. 

Next, the DCN determines the card status in step 342. If j 
there is no card inserted in the card reader, the DCN sets the i 
current message variable to an attract message. This mes- 
sage specifies that the player tracking node is to display a 
message which will attract players to the machine. Similarly, 
the DCN sets the current bezel color and bezel rate to an 
attract bezel color and rate in step 346. This attract color and 
rate is part of the attract message that will be sent to the 
player tracking node when the current message is sent 

If the DCN determines that a good card has been inserted : 
in the card reader, the DCN processes the valid card in step i 
350. This step is described further below with reference to i 
FIG. 21. 

If, however, the card status indicates that a bad card has ; 
been inserted, i.e., an invalid card number, the DCN sets the 
current message variable to specify a card error message in 
352 and the DCN sets the current bezel color and bezel rate 
to a card error color and rate in 354. This card error 
information is included with the card error message that is 
sent to the player tracking node when the current message is 
sent. 

7. PROCESSING CARD INSERTION 

Referring now to FIG. 21, the process 350 for processing \ 
a valid card insertion is shown. The first step that the DCN j 
executes is to determine whether the card data correspond- i 
ing to the valid card has been received from the floor: 
controller in step 356. If not, the DCN builds a network! 
request message for the player name and points associated 
with the card ID number in step 358. Next, the DCN sets the 
current message variable to specify a card inserted message 
is to be transmitted in step 360. Finally, the DCN sets the 
current bezel color and rate to a card inserted color and rate, 
which indicates to the player that the system is still pro- 
cessing the card number. This information is sent to the 
player tracking node when the current message is sent. 

If the card data has been received from the floor; 
controller, the DCN then determines in step 366 whether \ 
player tracking has started for the particular player. If player j 
tracking has not yet started, the DCN sets the current i 
message variable to the data received message in step 368 i 
and sets the current bezel color and rate to data received i 
color and rate in step 370. If player tracking has started, the i 
DCN processes the player tracking in step 372, as described 
with reference to FIG. 22. 

Processing player tracking 372 begins with the step of 
determining whether the player has received new points in 
374. These points can be considered roughly as the equiva- 
lent of "frequent flyer miles" used by airlines. These points 
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allow the system to run promotionals whereby individuals 
are given points or credit associated with their card that can 
be redeemed toward the purchase of goods or services 
offered by the casino. Typically these points are redeemed at 
5 a redemption counter in the casino for meals or clothing, for 
example. The points, therefore, are an additional inducement 
to encourage play. 

The player tracking system of the invention allows the 
casino to determine how and when the player is issued 
10 points. The casino can specify the type and number of coins 
that must be played before a player is awarded a given 
number of points. The system uses this specified information 
to inform the player of his or her progress towards receiving 
additional points. The system encourages play by Morming \ 
is the player of how many additional coins must be played i 
before receiving additional points. For example, a player 
who is only one coin away from receiving points, but who 
desires to stop playing, may decide to play "one last coin" 
in order to receive the points. The system informs the player i 
20 by displaying a message on the vacuum florescent display i 
indicating how many coins the player is away from receiv- i 
ing additional points. 

Referring now to FIG. 22, player tracking 372 begins with \ 
the step of <fctennining whether the player has received new \ 
25 points in 374. If no new points have been received, the DCN I 
sets the current message variable to specify a countdown i 
message in step 376 and sets the current bezel color and i 
bezel rate to a countdown bezel color and rate in step 378. I 
The countdown bezel color and rate indicates the player's 
30 progress towards being awarded additional points. 

If new points have been received, such as where the 
player has played a given number of coins, the DCN sets the 
current message variable to a points won message in step 
382 and sets the current bezel color and rate to a points won 
35 color andrate in step 384. The points won message informs 
the player of the number of points won. 

The above-described tracking process provides a means 
forproviding visual feedback to the player inserting the card 
into the card reader. By modifying the bezel color and bezel I 
40 rate, the data communication node provides immediate \ 
feedback to the player concerning the proper insertion of the 
card. If the player inserts the card properly into the card 
reader so that the card reader senses a valid user identifica- 
tion number, the card reader provides positive visual feed- 
45 back to the user by Ruminating the bezel. On the other hand, i 
if the user improperly inserts the card so that the card reader \ 
cannot read the user identification number, the card reader i 
can provide negative visual feedback to the player by i 
muminating the bezel with a different color and/or flashing 
so rate. In the preferred embodiment, this positive visual feed- i 
back includes flashing the green LEDs to produce a flashing 
green signal around the card reader opening. The negative 
visual feedback includes flashing the red LEDs. A third i 
combination color is used during the processing of the ! 
55 player tracking information. This process provides immedi- 
ate feedback to the player concerning the insertion of the 
card in the card reader. 
B. PLAYER TRACKING MODULE 
The system described above allows for improved player 
60 tracking by recording each and every machine transaction 
including: time of play, machine number, duration of play, I 
coins in, coins out, hand paid jackpots and games played, i 
The player tracking is conducted over the same network as 
the accounting data is extracted. This allows the invention to 
65 provide bonusing to certain individual players as well as 
during certain times. As with standard player tracking, the ^ 
above-described system monitors and reports how many 
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coins are played by each player. The system according to the 
invention, however, also includes the ability to record how 
long each player spends at each machine and the number of 
coins won, games played, and hand jackpots won by each 
player. The system is able to record all mis information 
because the it operates on a transaction by transaction basis. 
Each transaction, whether it be a coin in, a handle pull, etc., 
is recorded by the system. Other prior art systems simply 
compile the player tracking information at the completion of 
play. 

All the transaction information is stored on the database, 
which can be later analyzed for future targeted direct mailing 
campaigns. The player tracking according to the invention 
allows the casino to schedule buses and other groups and 
measure their profitability. Because the system records each 
transaction, the casino can reconfigure theft casinos to better 
match the tastes and demands of their customers. 

The improved player tracking according to the invention 
also allows the casino to calculate theoretical wins exactly 
because the system always includes the most current infor- 
mation. The operation of the player tracking procedure is 
described below. 

1. POWER UP PROCEDURE 

The operation of the player tracking module will now be ; 
described with reference to FIG. 23 where the powerup | 
process 400 for the player tracking node is shown. As in the j 
data communication node, the player tracking node first j 
validates the RAM and sets up its associated hardware in i 
step 402. Next, the player tracking node tests the RAM in 
step 404 to determine whether the RAM is functioning 
properly. If not, the player tracking node, i.e., player tracking 
controller, terminates its program in an error condition in 
step 406. If the player tracking RAM is fully functional, the 
player tracking node sequentially executes steps 408-414. In 
step 408 the player tracking controller processes the DCN i 
interface between the player tracking controller and the \ 
DCN controller. In step 410 the player tracking controller ! 
updates the player tracking display. In step 412 the player : 
tracking controller updates the bezel. Finally, the player i 
tracking controller processes the card reader in step 414. j 
Each of these steps will now be described further below. 

2. PROCESSING DCN INTERFACE 

Referring now to FIG. 24, the steps for processing the 
DCN interface are shown. First, the player tracking control- 
ler checks for a new message received from the DCN in step 
416. Ira new message has been received, the player tracking 
controller overwrites its current message buffer with the new 
message and updates the bezel color and rate values with 
those contained in the new current message. Then, the player 
tracking controller builds a card status reply message in step 
420. The card status message indicates whether a card has : 
been inserted and if so whether the card was a good card or : 
a bad card, Le., the card was read properly by the card reader, i 
If a valid card, the card status reply message also includes j 
the identification number encoded on the card. This step 
might also involve transposing the number encoded on the i 
card depending on the orientation in which the card was j 
inserted into the card reader. This card status reply message j 
in then sent to the DCN in step 422. 

3. PROCESSING DISPLAY UPDATE 

The process of updating the player tracking display is 
shown in FIG. 25 at 410. This process begins with the player 
tracking controller scanning the display message for display 
attribute information. Examples of such display attribute 
information is given below in Table 4. Each display attribute 
specifies a different graphic mode for the player tracking 
display. 
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TABLE 4— DISPLAY ATTRIBUTE 
INFORMATION 

1. Hash Rate 
5 2. Center Display 

3. Set Display Intensity 

4. Use Small Lower Font 

5. Use Small Upper Font 
10 6. Use Normal Large Font 

7. Set Pause Time 

8. Set Scroll Speed 

9. Center and Melt 

10. Center and Scroll Down 
15 11. Center and Scroll Up 

12. Scroll Down and Stop 

13. Scroll UP and Stop 

14. Scroll Left and Stop and End of Message 
20 15. Scroll Down 

16. Scroll Up 

17. Scroll Right 

18. Scroll Left 

2J 19. Reverse Video 
20. Normal 

The player tracking controller then determines whether 
any such attribute information is found in the display 
message. If so, the player tracking controller sets up the 

30 display driver to incorporate the graphics mode specified by 
the attribute information. The player tracking controller then 
strips out any display attribute information from the display 
message in step 432 because the display attribute informa- 
tion is embedded in the display message. The remaining data 

35 in the display message is the actual text to be displayed by 
the player tracking display, e.g., the player's name. The 
player tracking controller then sends this text to the display 
in step 434, which is then displayed by the player tracking 
display. 

40 4. PROCESSING BEZEL UPDATE 

The player tracking node is also responsible for updating 
the bezel, both in terms of its color and flashing rate. This 
process 412 is shown in FIG. 26. The first step in processing 
the bezel update is to determine to bezel color as specified 

45 by the DCN and then drive the appropriate LEDs in the card 
reader. As described above, the preferred embodiment of the 
card reader includes dual diodes having two primary colored 
diodes that can be driven separately or in combination to 
produce three different colors. 

so Next, the process determines the bezel rate as specified by 
the DCN. In a first case, the bezel rate is zero or off and thus 
the player tracking controller turns the LEDs off in step 442 
in this case. If the bezel rate specifies a flashing rate, the 
player tracking controller flashes the bezel at the appropriate 

55 bezel rate in step 442. Flashing the bezel involves turning 
the LEDs on and off at the specified rate. This can be 
accomplished by a timer interrupt or a timing loop executed 
by the player tracking controller. The final option is that the 
rate can be infinite or effectively a solid bezel color. In mis 

go case, the player tracking controller simply leaves the card 
reader LEDs on in step 446. This completes me processing 
bezel update process 412. 

5. PROCESSING CARD READER 

The next process step for the player tracking node is to 

65 process the card reader. This process 414 is shown in FIG. 
27. The first step is for the player tracking controller to 
determine the card status in 450. In the preferred 
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embodiment, the card status is determined by comparing the 
checksum of the card, as read off the card by the card reader, 
to a computed checksum of the data read off the card. Other 
methods of determining card status can be used as well 
depending on the type of card reader employed. 

If the player tracking controller determines that a valid 
card was inserted in the card reader, the player tracking 
controller sets a card status variable equal to good card. This 
card status is then subsequently transmitted to the DCN 
controller. Then, the player tracking controller sets a card ID 
variable equal to the identification number read by the card 
reader in step 454. The card status and the card ID provide 
the DCN with sufficient information to instigate the player 
tracking. 

If, on the other hand, the card reader indicates that the 
card was read improperly or that the card is an invalid card : 
for the card reader, the player tracking controller sets the 
card status variable to bad card in step 458 and the card ID 
variable is cleared in step 460. If neither a valid or invalid 
card condition was detected in 450, the player tracking 
controller sets the card status variable to no card in step 462 : 
and clears out the card ID in 460. 
C. FLOOR CONTROLLER 

1. POWER UP PROCEDURE 

Referring now to FIGS. 28-32, the process 464 operable j 
on the floor controller will now be described. The process j 
464 is shown in FIGS. 28-32 in flow chart forms. These flow : 
charts would enable one of ordinary skill in the art to I 
implement the process in computer software using an appro- \ 
priate computer programming language. 

The floor controller process 464 begins at step 466 by I 
opening the database tables in the file server. As described ; 
above, the file server includes a commercially-available 
database program which stores the machine activity infor- 
mation as well as player tracking information and associated 
system characteristic parameters. This step 466 can also 
include fetching some or all of these system characteristics 
in order to trigger certain events such as bonus jackpots, as 
described below. 

In step 468, the floor controller terminates any active ; 
player tracking sessions in the database. Because player i 
tracking may have been in progress when the floor controller ; 
became inoperable, when the floor controller powers up or ; 
becomes operable, there may be player tracking sessions i 
initially active. In this step, the floor controller terminates \ 
any such active player tracking sessions in order to place the I 
database in an initial state. 

Another step that the floor controller executes after 
becoming operable is to place an initial machine search 
message in an output message queue 470. This search 
message is used by the floor controller to determine which 
machines are connected to the floor controller. This output \ 
message is subsequently transmitted to all of the machines i 
coupled to the floor controller using a global message ; 
format as described below with reference to FIG. 31. In the I 
preferred embodiment of the invention, the message nan- \ 
dling is through the use of message queues. Furthermore, the \ 
preferred embodiment is both an output queue for outgoing I 
messages from the floor controller to the machines and an 
input message queue for messages coming from the 
machines to the floor controller. Queues are well-known 
data structures in the art of computer science and are 
therefore not further discussed herein. Alternatively, the 
message-handling could be done without the use of the j 
queues. In such an embodiment the outgoing messages i 
would be sent immediately rather than being queued, and j 
any incoming messages would be processed immediately. I 
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which indicates whether the floor controller needs to 
respond to any previous message. If a response is pending, 
the floor controller queues up an appropriate outgoing 
message in the output message queue in step 492. 
Otherwise, the floor controller completes the message pro- 
cessing step 472. 

Referring now to FIG. 30, the message-handling step 488 
is shown in more detail. The message-handling step begins 
by verifying that the message data corresponds to a valid 
message in step 496. In the preferred embodiment, the 
message includes a cyclical redundancy check (CRC) by 
which the floor controller can determine whether the mes- 
sage is valid or corrupt. Only if the message is valid will the 
floor controller perform any additional message-handling 
steps. The floor controller also parses through the message 
in step 496 to determine what type the message is. The 
message type determines the appropriate floor controller 
action. In the preferred embodiment, the messages include a 
command code which indicates the type of message. 

The first type of message can be one which includes new 
meter information. The floor controller checks in step 498 to 
determine whether the message includes this type of infor- 
mation. If the message includes new meter information, the 
floor controller saves the new meter information locally in 
step 500. The floor controller maintains local copies of the 
meter information in order to minimize the amount of traffic 
on the high-speed network. Because the machine meters 
change so rapidly, forwarding this new meter information on 
to the file server each time one of these meters is altered 
would produce an excessive amount of network traffic on the 
high-speed network. Therefore, in the preferred 
embodiment, the floor controller saves this new meter infor- 
mation locally in step 500 and only forwards the new 
information on to the file server after a predetermined 
amount of time has elapsed. 

Another type of message is one which requests data. The 
floor controller checks in step 502 to determine whether the 
message type is one requesting data. Typically, these data 
requests will be for player tracking information such as j 
where a player inserts a card into a card reader whereupon I 
the data communication associated therewith sends the : 
identification number encoded on the card to the floor \ 
controller requesting the player tracking data associated with i 
the player identification number. If the floor controller \ 
detects a data request in step 502, the floor controller looks : 
up the requested data in the database on the file server in step : 
504. Also, in step 504, the floor controller marks a response : 
pending in the transactions in progress structure to indicate i 
that this requested data needs to be sent back to the DCN. As i 
described above, the floor controller queues up outgoing ; 
messages responsive to the transactions in progress struc- j 
ture. 

Another message type is one used by the floor controller i 
to establish new machine addresses. The floor controller ; 
periodically checks to determine whether any new DCN has I 
been coupled to its associated current loop networks in order 
to assign a unique address to that machine. In step 506, the 
floor controller checks to see whether the incoming message 
is in response to such a process. If the incoming message is 
in response to a machine, search, the floor controller assigns 
a new machine address to the responding machine in step 
508. The entire process of assigning new machine addresses 
is described below with reference to FIG. 31. 

Finally, the floor controller in step 510 handles any 
miscellaneous messages. These miscellaneous messages are 
used primarily for debugging and trouble-shooting the 
machines. 
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3. ASSIGNING GAMING DEVICE ADDRESSES 
As described above, in the preferred embodiment of the 
invention, the floor controller uses a shorthand token rep- 
resentation of the DCN's unique identification number to 

5 address the DCN. In the preferred embodiment, a single byte i 
address is used to address a DCN on any given current loop. 
This one-byte address allows up to 256 DCNs to be sup- j 
ported on any given current loop network. In the preferred 
embodiment, only 64 such DCNs are connected to a single 

10 current loop network and therefore the single byte address is 
more than adequate. The single byte address substantially 
reduces the amount of traffic on the current loop network by 
reducing the number of bytes from four in the unique 
identification number to one for the shorthand token repre- 

is sentation. 

The floor controller is responsible for generating the j 
unique single byte address for each data communication ; 
node on a given current loop network. The process 508 of i 
assigning unique addresses to the DCNs on the current loop i 

20 network is shown in FIG. 31. The process begins by defining : 
a range of unique identification numbers in step 512. Ini- i 
tially mis will be a large range. 

Next, the floor controller sends out a message to all of the 
DCNs on the current loop network in step 514. The floor 

25 controller communicates with the DCNs by using a standard 
communication protocol. In the preferred embodiment, this 
protocol defines a message format including a destination ; 
ID, a source ID, a message length, a data packet and a CRC. ; 
Other message formats could be used as well. Using this : 

30 format, the floor controller can communicate with all of the 
DCNs on the current loop network by using a global 
destination address in the message. This global destination 
address would indicate to the DCNs that this message is 
intended for all DCNs on the current loop network. This 

35 global message would include two unique identification 
numbers that, taken together, define the range of unique 
identification numbers established in step 512. 

The individual DCNs then checks to see whether their 
unique identification number falls within this range. If a 

40 DCN's unique identification number falls within this range 
and the DCN does not have an address assigned thereto, the 
DCN then responds to this global message by sending a 
reply message in response that includes the unique identi- 
fication number of that DCN. In the event that more than one i 

45 DCN has a unique identification number that faUs within this i 
range a network collision will occur and the message will be i 
corrupted. The process 508 checks for this condition in step ; 
516. This condition is indicated by an invalid CRC in the ; 
message. 

50 In the event of a network collision, the floor controller can ; 
limit the range of unique identification numbers by repeating i 
step 512 in the hope of eliminating mis network contention. i 
If the response has a valid CRC, the floor controller 
assigns a unique address to the responding DCN, as iden- 

55 tified by the unique identification number in the response, in 
step 518. The floor controller then transmits this address 
along with the corresponding unique identification number 
in an assignment message to all of the DCNs using a global 
destination address in step 520. The DCNs then process this 

60 message and in the event that the unique identification 
number included in the message corresponds to the DCN's 
unique identification number, the DCN adepts the address 
included in the message. Once the DCN has been assigned 
an address in this manner, the DCN will interpret all 

65 subsequent messages having a destination address equal to 
the assigned DCN address as being directed to that DCN. 
The above-described address assignment sequence is 
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repeated for each of the remaining DCNs on the current loop 
network in step 522. The floor controller continues this 
process until the entire range of unique identification num- 
bers has been covered and no more network collisions occur. 
4. SYSTEM MONITORING 

Referring now to FIG. 32, the system monitoring step 474 
will now be described. The floor controller is now respon- 
sible for monitoring certain system-wide conditions to deter- : 
mine whether certain events need to occur. The system 
monitoring step also handles request for particular machine 
information. Thus, in step 524. the floor controller deter- 
mines whether a new request has been placed in the data 
base for such particular machine information. If such a 
request has been placed, the floor controller responds to the 
special request for data in step 526 by sending a message to ; 
the particular machine requesting the required information. 
Once the required information has been received, the floor \ 
controller processes this information accordingly. 

The floor controller also monitors the locally-stored meter 
information in step 528. If the locally-stored information is 
changed, the floor controller saves the latest information to 
the data base in step 530. As described above, the floor 
controller saves the meter information locally in order to 
minimize the traffic to the file server over the high speed 
network. 

The floor controller also monitors the system for certain 
event triggers in step 532. These triggers can be stored in the 
data base and fetched by Ihe floor controller during its 
power-up procedures. These triggers indicate if and when 
certain events occur. Examples of event triggers include: the 
drop period, the end-of-day, the bonus period, etc. If an 
event trigger has occurred, the floor controller handles the 
event in step 534. 

The handle event step 534 is shown in more detail in FIG. 
33. The events can basically be bifurcated into accounting 
events and bonusing events. Accounting events refer to the 
data communication activity of the system. The accounting 
events are typically triggered by a certain time of day such 
as the end of day or the drop period. If an accounting event 
has been triggered, the floor controller performs the required 
data base operations in step 538. This step involves updating 
all of the locally-stored meter information and storing the i 
updated meter information into the data base. 

The other type of event can be referred to as a bonusing i 
event. The floor controller checks to see whether the event i 
is a bonusing event in step 540. The bonusing events can i 
also be triggered by the time of day. For example, the i 
bonusing event may be triggered from midnight to 4:00 a.m. j 
on weekdays. These bonusing periods can be specified in the i 
data base. If the triggered event is a bonusing event, the floor ; 
controller inserts a corresponding reconfiguration message ; 
in the output message queue in step 542. The reconfiguration I 
message includes a reconfiguration command that is sent to : 
an appropriate machine. The machine, upon receiving the : 
reconfiguration command, reconfigures its payout schedule i 
in accordance with the received reconfiguration command. i 
According to the invention, there are many different recon- I 
figuration commands to implement a multiplicity of different : 
bonusing events. One reconfiguration command specifies : 
that the machine should reconfigure its payout schedule to 
be a multiple of its default payout schedule. This reconfigu- i 
ration command can also specify that the multiple payout 
schedule should be limited to a predetermined percentage of 
the coins in. This reconfiguration command can further 
specify that the multiple payout schedule should be limited 
to only when the maximum coins are played. This recon- 
figuration command can further specify that the multiple 
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payout schedule should be limited to payouts in a specified 
range. This reconfiguration command can also specify the 
multiple payout schedule should payout only when a pre- 
determined level of player activity is reached. 

5 Another reconfiguration command allows any number of 
machines on the network to be combined in a common 
jackpot having a common jackpot payout schedule, wherein 
the reconfiguration command reconfigures the selected 
machines to payout in accordance with the common jackpot 

10 payout schedule. In this case, the reconfiguration message 
would be queued up for each of the selected machines to be 
combined in a common jackpot One example of a common 
jackpot is a progressive jackpot. Unlike the prior art pro- I 
gressive jackpot systems, however, the progressive jackpot I 

is according to the invention is not limited to a predetermined j 
number of machines. In the prior art progressive jackpot j 
systems, a bank of machines are connected to a common i 
progressive jackpot controller and only those machines can 
be included in the progressive jackpot In contrast, any 

20 machine on the network, including those connected to other i 
floor controllers can be combined into a common progres- i 
sive jackpot. Moreover, the number of progressive jackpots 
is not limited by the number of floor controllers since one 
floor controller can manage more than one progressive 

25 jackpot. 

Another reconfiguration command permits the system to i 
implement so-called "automatic mystery jackpots." These i 
"mystery" jackpots allow a machine to payout a mystery j 
jackpot even when a jackpot was not won. Instead, the 

30 reconfiguration command can specify that the mystery jack- 
pot is to occur after a certain number of coins, a certain 
number of handle pulls, or a variety of other conditions 
specified by the reconfiguration commands. These mystery 
bonuses provide the casino with another way to induce 

35 additional gaming activity. 
5. BONUS CONTROL 

Referring now to FIG. 34, a method 550 for controlling 
the conditions under which the above-described bonus 
activities are activated is shown. It is essential for the system | 

40 to have complete control over the amount and conditions j 
under which a bonus is paid out in order to insure the i 
profitability of the bonusing system. The method 550 \ 
described below provides the required control. 
The method 550 begins in step 552 by disabling or turning i 

45 off the bonuses in the individual machines. This is accom- 
plished by sending a message to the individual DCNs to turn i 
off or deactivate bonusing. Next, the floor controller moni- i 
tors the activities of the individual machines connected 
thereto. This step includes monitoring the coins in and 

so bonuses paid for the individual machines, as described i 
above. In step 556, the floor controller modifies a bonus pool i 
by a predetermined percentage of all coins played. The \ 
bonus pool is essentially a pool of monetary resources that I 
can be allocated for bonus awards. In the preferred i 

55 embodiment, a predetermined percentage of the monetary 
value of the coins played are added to the bonus pool. Also 
in this step, any bonuses paid by the gaming devices are also 
measured and subtracted from the bonus pool. The use of the j 
bonus pool will become more apparent when the other steps j 

60 are described hereinbelow. 

In step 558, the floor controller determines whether or not 
bonusing is active. If bonusing is active, the floor controller I 
next determines whether the bonus pool amount has dropped 
below a predetermined minimum level called the "turn-off" 

65 level in 560. This minimum amount or floor can be set by the I 
casino and provides a buffer to account for large bonus 
awards and/or multiple bonus awards that could cause the 
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bonus payout to exceed the bonus pool. Therefore, if the : 
bonus pool drops below the turn-off level, the method 550 
£""^2. bacl F to L ^ 552 and to™ 5 off bonusing. As will 
desmbed further below, the bonusing remains off until such i 
^fftoetonus pool builds "PPastanothexminimumlevel 
called the "turn-on" level. 

Returning to step 558, if the bonus is currently not active, I 
the floor controller determines at step 562 whether the bonus 
pool has reached a predetermined turn-on level This turn-on 
level can also be set by the casino and provides a buffer 
above the turn-off level to insure that the bonusing does not i 

£S? y d e -' bonusing rapidIy switchJn g betw «* 

on and off. If the bonus pool is not above the turn-on level, 
bonusing is again turned off in step 552. 

If the bonus pool has reached the turn-on level, the floor 
controller checks to see whether other bonus conditions are 
met at step 564. These bonus conditions can include, but are 
not limited to, a minimum period of time 'since the last i 
bonus activation, a niinimum level of play in the time period 
prior to the bonus pool reaching the turn on level, a ! 
predetermined time of day, or other predetermined condi- 
tions. These conditions give the casino additional control 
over the bonusing promotions. If the conditions are not met, ! 
the method 550 branches back to step 552 where the 
bonusing is again turned off. If, however, the conditions are 
met in step 564, the bonus is turned on at step 566 and the i 
method 550 branches to step 554 where the machine activity 
is again monitored. : 
In the preferred embodiment, the method 550 is embodied ^ 
in software that is executed by each of the floor controllers 
rn the system. These floor controllers are then responsible i 
for activating or deactivating the bonusing for the individual I 
machines connected thereto. The system allows the floor 
controller to have multiple bonus pools and to have certain \ 
of the machines associated with a given bonus pool. Thus, I 
the floor controller can implement multiple bonusing pro- 
motions simultaneously. 

This system also allows for machines connected to dif- j 
ferent floor controllers to be combined into a single bonus- 
ing promotion. In this case, one of the floor controllers i 
assumes primary responsibffity for managing the bonus pool ! 
while the other floor controllers act as intermediaries 
between the primary floor controller and the machines 1 
connected to the other floor controllers. Thus, the system ! 
according to the invention allows for much greater flexibility 
m running bonusing promotionals than heretofore possible. ! 
Prior art systems required certain predetermined machines to i 
be connected into a bank for any given bonus award such as 
a progressive bonus. The system according to the invention I 
allows any machine in the casino to be combined in a bonus I 
type situation. The system also insures that the bonusing 
promotionals will operate substantially in the black, i.e., the 
bonus pool is greater than the bonus payouts. 

Having described and illustrated the principles of the 
invention in a preferred embodiment thereof, it should be 
apparent that the invention can be modified in arrangement 1 
and detail without departing from such principles. For 
example, although an Ethernet network was described in the 
preferred embodiment of the invention, other high-speed ! 
networks such as wireless networks could be used in place 
thereof. I claim all modifications and variation coming 
within the spirit and scope of the following claims i 
We claim: 

1. A method of operating gaming devices configured to 
play a preselected game interconnected by a computer 
network to a host computer comprising: 

permitting players to play the preselected game at ftj 
gaming devices; 



